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
Related
We have our own payment processing system. This takes a customer token from Stripe's response after initially checking out, and uses it each month to charge the customers card.
We want to do similar for mobile wallets, like Apple Pay.
However, Stripe docs indicate that it only returns a token which is 'single use', so the customer would have to authenticate the payment each month:
We aren't able to integrate with Stripe's 'subscriptions' service, as we'd have to migrate across entirely to Stripe - which we can't do.
So as a result, is it possible to get a reusable token - or does the 'subscription' it's referring to mean that we can get a reusable token in the same way as a standard card payment?
And by reusable token - I mean, the customer doesn't need to authenticate the payment each month.
Hope that makes sense!
When you accept an Apple Pay payment, you can still save the underlying card for future payments. This will then work whether you use Billing (their recurring payments product) or just create one-time payments yourself.
The call out from Stripe in their docs is more around the rules coming from Apple. If your customer is checking out in your application or website, you are expected to show them the Apple Pay UI to confirm the payment again instead of using a previously saved card. On the other hand, if you are doing recurring payments, you can use the previously saved card for future payments.
The integration itself is fairly straightforward. You would create a PaymentIntent server-side and collect the card details client-side whether via Apple Pay or not. Since you want to save card details for future payments you would also pass setup_future_usage: 'off_session' on the PaymentIntent creation. After a successful payment, a PaymentMethod of type card would be attached to the customer with the id pm_123 and you could use this in future recurring payments.
This flow is covered in Stripe docs here and also applies to Apple Pay and this section covers how to make the future payments.
I am creating subscriptions upon completing the Stripe Checkout session and from what I have read, stripe supports 3d secure authentication payment on its checkout session. However, if this is true for the first time the client pays for the subscription (stripe will ask him to enter a code on the checkout session page), how will that be applicable for the remaining payments in the following months? Where will the user enter the code?
Assuming you are using Stripe Billing, your user will be automatically charged on recurring months. So they usually only have to complete 3DS for the initial payment. But if the card issuer requires 3DS to be fulfilled every invoice, you can configure your Stripe settings to automatically email your user to complete 3DS on a Stripe hosted page. However, if you want to write custom failure handling, you will need to add a webhook for customer.subscription.updated and check if the status is past_due.
https://stripe.com/docs/billing/subscriptions/overview#recurring-charges
In my case, Just added off_session when you create charge about user.
$user->charge($price, $paymentMethod, ['off_session' => true]);
Hopefully, it would be worked for you.
I am working with the Stripe API and I cannot find enough documentation regarding the on_session scenario.
I am saving the card after the first payment and setting the 'setup_future_usage' to 'on_session' because the customer is going to be always present in the checkout flow. However, this triggers authentication every time I try to pay something with the credit card number (4000002500003155). This type of credit card is intended to show only once the authentication process and to use the saved card for the subsequent off-session payment.
It's still totally possible that the issuing bank will require that you authenticate the future on-session payments. I don't think there's a test card to test the specific case you're trying to test though: https://stripe.com/docs/testing#regulatory-cards
I've making a SaaS that allows customers to subscribe to a plan, and use coupons at the checkout stage. The coupons give the customers X% off for X months, and by default, everyone gets a 7 day trial when they subscribe.
What is confusing me is the documentation. In one section it says that you should create SetupIntents to take a payment and elsewhere it says to use tokens.
I'm in the middle of coding the payment flow, but I just wanted to check to see if my logic and understanding is correct. Could anyone validate the below?
Customer enters card number and coupon
Call Stripe, get token for card
Send token and coupon to server
Create Stripe customer with token
Create Subscription with discount and pass customer ID
What has now happened is an authorisation attempt was made. If SCA is required, then the subscription status is incomplete and the latest invoice payment intent status requires action.
At this point, I can redirect my user to the SCA Flow using handleCardPayment() to prompt 3DS, and once complete the subscription status is then active.
If the invoice payment fails for any reason, then the subscription state is incomplete and the payment intent requires has a payment action required status. At this point, I should present my customer with the React Elements form again, and call the stripe.invoices.pay endpoint with the new card token
Going forwards, all subscription charges should not need further SCA approval, however if the customer changes plan or the bank requests it, then I can point my user back through the SCA Flow process
A diagram of the flow is here: Green is UI, Orange is Server, Blue is Stripe
Is there anything I have missed or misunderstood here? I've been reading about creating SetupIntents and PaymentIntents, but I'm not sure I need this?
If you are creating subscriptions using the Stripe Billing product they handle creating the PaymentIntent(if you are taking a payment immediately) or a SetupIntent (if you are setting up a trial or metered billing). All that you really have to do different is handleCardPayment (for payments) or handleCardSetup (for setting up trials and metered billing). This section in the docs is pretty good.
If you are not using billing they have a video on their Stripe Developers Youtube channel which may help clear up any confusion.
Hope this helps :)
Welcome fellow sufferer, cards and tokens are implemented in Stripe Charges API which is not SCA compilant. If you want use Stripe for payments inside the EU you should use payment intents.
Card tokens are also allowed for creating payment intents.
But if you want reduce the number of necessary authentications you should use setup intents (with usage = "off-session") for creating payment methods and not card tokens.
I have a lot of old customers who have still registered with the Charges API. I use the following strategy:
New customers always register via Setup Intents and Payment Methods.
Old customers use the Charges API until their tokens become invalid. Then they must also use setup intents and payment methods.
Of course, the customers do not notice much of it.
In summary, I would always use payment methods and setup intents for new customers and card updates. Only with the setup intents can you ensure that your customers have to authenticate themselves as rarely as possible.
EDIT: The crucial point is off-session payments that occur with subscriptions. The Stripe procedure is described here: https://stripe.com/docs/payments/cards/saving-cards#saving-card-without-payment
How can I tell from the stripe api -
A user has cancelled their subscription?
A user's credit card is no longer valid.
Is there anyway round having to call the stripe API every time the user logs in to check these facts?
Handling cancellations is purely the responsibility of your application—users don't have an interface to Stripe. If they're canceling, they're doing it through whatever account management system you provide. You should thus be tracking cancellations in your own database. Whatever database you're using, add a subscription status field and update it when a user cancels or re-subscribes.
As for tracking invalid cards, Stripe provides notifications of billing failures—and many other useful events—via webhooks. In most cases, if you're not implementing a webhook responder, you're working much too hard on your billing infrastructure. Stripe is built to push a wide variety of information to you; polling the API yourself is just overcomplicating things for most purposes.