So in our app, we do not charge immediately but simply create stripe charge with capture set to false so that customer is not charged instantly.
Question: Should we still issue a Refund for the customer (in case of app/db error) despite the fact that we created a charge in un-captured mode ?
Thanks for the help
Ideally, yes, you should. "Refunding" an uncaptured charge will cancel the authorization and release the funds on the customer's account.
If you don't refund the uncaptured charge, the authorization will automatically expire after 7 days, but that's not very customer friendly. You should always try to either capture or refund uncaptured charges as soon as possible.
Related
Imagine the following case:
I buy a monthly subscription - subscription is successfully created in Stripe.
When the next billing period comes, my card is already expired (or there is no fund in it) so the renewal fails.
I had an idea to use a valid test card first and then create another payment method with an expired card. However, Stripe won't allow me to add that kind of payment methods.
How can I test this scenario?
Stripe has a great test card[1] for this kind of error. You can add it to a customer but it will fail any payment.
4000000000000341 Attaching this card to a Customer object succeeds, but attempts to charge the customer fail.
For this kind of test, I typically create a customer, attach that card to them, and create a subscription with a trial period[2] of 10 seconds. After the trial is over, I manually finalize and try to take payment on the invoice to cause the renewal failure.
[1] https://stripe.com/docs/testing
[2] https://stripe.com/docs/api/subscriptions/create#create_subscription-trial_end
I know I can pre-auth a stripe subscription with a trial period. I want to pre-auth the 2nd, 3rd, 4th, nth subscription payment. The info we are sending out is time critical and if their subscription lapses due to NSF or something else, it would be nice for them if they could rectify the problem BEFORE it lapses.
There is a pending invoice you can get for a subscription, and you can create a payment intent with an invoice ID so that when the invoice is paid, the payment intent (that captured the money) will be used to collect the money. BUT the pending invoice doesn't have an ID until one or 2 hours before they try to collect the money which is 3-4 days too late.
Has anyone figured out how to pre-auth subscription payments other than the first one?
Is there a subscription engine I could use (with stripe/paypal/venmo) that would mean I could quit using the deficient stripe subscription system?
Subscription invoices don't exist until the renewal of the billing cycle, and the underlying payment intent is created by the invoice. It's not supported to "pre-auth" subscription payments. Instead, you need to handle payment failures when those occur, optionally by letting Stripe handle that for you.
If you want to have successful payment in advance of some time-sensitive event, then I'd suggest one of two alternatives:
Shift your billing cycle to invoice 3-4 days ahead of what you have set now, allowing you time to recover from payment failures before the delivery timing.
Alternatively you would implement your own recurring payments using saved payment details. You would similarly want to authorize the payment ahead of time to allow for recovery. You could optionally use manual capture to defer capture until the time of delivery.
Before migrating to the Payment Intents API the user's credit card payment was confirmed and charged on the server side using the token (received from stripe.createToken) after the purchase has been completed. This gave us the possibility not to confirm the payment in case any errors happens.
Now, with the Payment Intents API the payment confirmation happens already on the client side (stripe.confirmCardPayment) which is a problem in case an error happens on the server side while completing the purchase as the credit card has already been charged. A refund is not valid solution your Stripe fees won't be refunded.
How can we implement card payments with the Payment Intents API but confirm the payment at the final end of the purchase (as in the legacy workflow)? Or how can we prevent the credit card from being charged in case an error occurs during the checkout workflow?
Unfortunately, we couldn't find a solution to this problem in the documentation.
Help appreciated!
Here are the docs: https://stripe.com/docs/payments/payment-intents/migration
What you are looking for is modeled via "manual confirmation" of a PaymentIntent: https://stripe.com/docs/payments/accept-a-payment-synchronously.
It isn't Stripe's recommended integration. The recommended approach is to confirm client-side and listen to webhooks for payment confirmation.
This is because with manual confirmation, there is a higher chance of customer "drop off" where they authenticate your PaymentIntent on your webpage but close it out, meaning you lose your client->server roundtrip, leaving your payment unconfirmed (eventhough the customer thinks they authenticated hence paid).
Additionally, manual confirmation only works for card type payments, it is not supported for other payment methods based in other regions like iDEAL or SEPA Debit etc.
In our case, we wanted to authenticate the card payment at the end directly after making the charge. The Stripe support was able to help us with the following answer:
As I understand you would like to authenticate the payment at the end directly after making the charge. There is a solution to this, with the capture_method being set to Manual - https://stripe.com/docs/api/payment_intents/create#create_payment_intent-capture_method. What this would mean is, that the charge will be made and the user / client would be able to confirm the payment afterwards in the Dashboard directly.
This method is called Auth and Capture. Place a hold on a card to reserve funds now but only capture them after your business completes the service. When a payment is authorized, the bank guarantees the amount and holds it on the customer’s card for up to seven days, or two days for in-person payments using Terminal. You can find more information along with the API's under this Link: https://stripe.com/docs/payments/capture-later#authorize-only
We're just a few weeks away from releasing our custom built SaaS app for Freight Brokers and (eventually) Carriers. We're deciding how to handle failed credit card payments. The options have so far been:
Immediately restrict their account and require a payment. Send them an email saying an Admin can login and restore account access
or
Give them 7 full days to pay(including weekends), send them an email when the payment fails, a day after and 2 days after the second email. Then send them an email when their account access has been restricted. When they login, they can pay, but the payment would include the days used without payment.
I'm leaning towards the second one, because if I were a business owner, i would not want to come in and my employees are sitting because none of them have a company credit card to pay for the software.
Thoughts?
EDIT: Lmao I spelt "handle" wrong in the title... Fixed.
You can configure Stripe Dunning process which facilitates you to handle failed payments in a better way for subscription base billing.
Its basically enabling retry schedule with customize timeframe. you can cancel the subscription or mark the subscription as unpaid after all retry attempts have been exhausted. There is a webhook which indicates the transaction details, using that you can handle your business logic like hold the tenant or delete the tenant.
I am using Stripe in a 2 part payment process. i.e.
Pre-authorize the card calling the Charge object with capture = false
Do some database work
Charge the card using charge capture
Do, or should I attempt to cancel this pre-authorization, using the refund method, if step 2 fails (i.e. the DB work)?
I am concerned that if I don't then customers will get irate if they see a charge appear on their account for a couple of days. i.e. before it expires naturally.
If you know for sure you will not capture the charge, it's definitely better to cancel the authorization (by refunding the uncaptured charge) rather than letting it run out. The sooner you cancel the authorization, the sooner the charge will disappear from your customers' credit card statements.
From Stripe Documentation, there is no distinction between a VOID and REFUND, it's basically a reversal of the charge. A VOID would be issued if auth is not captured, that's my understanding.