My app requires a user to enter their payment method, which they may use for purchases in the future.
At the point of accepting the payment method:
Is it possible for stripe to know whether or not the payment method is valid and how much it can be charged?
As time passes, will stripe be able to know if the payment method has expired or know how much it can be charge as this values changes over time?
Yes, stripe knows the payment method validation. If it's not valid or expires stripe throws an error and you can catch it on your side and perform accordingly. If the purchase method expires stripes throws an error and retries at most 5 times (I guess, I forgot the exact number).
And the dynamicity, stripe charges the amount you want it to charge. You set the chargeable amount and stripe does its work.
Related
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 are working on a service that can start a subscription later in the future: users say today they want the service, but it actually starts some days later.
We are now collecting the payment method through a SetupIntent, which allows the user to verify they own card, but it actually doesn't verify the credit availability. When we collected the payment method, we create a scheduled subscription with the verified payment method; then, when the subscription starts, Stripe uses that payment method to collect money.
It happens, sometimes, that users do not have enough credit to pay for the service when the subscription starts. Otherwise, it also happens that, when Stripe tries to get money, the customer's bank requires 3D-secure verification.
Since our subscriptions start at midnight, we would like to avoid having to involve users again in the payment process.
So, we thought: would it be possible to immediately collect the payment method through an hold on a PaymentIntent and confirm that hold only when the subscription starts? I can't find a way to do this with Stripe (don't know if it exists). It seems impossible, with Stripe, to generate a PaymentIntent (with capture_method set to manual) for a scheduled subscription.
Do you have some ideas on how we can avoid payment problems when the subscription starts?
Otherwise, it also happens that, when Stripe tries to get money, the
customer's bank requires 3D-secure verification.
This shouldn't be the case if you complete any required 3DS authentication as a part of the SetupIntent confirmation flow. Call confirmCardSetup whilst the user is present and that way the payment method is successfully verified and can be used to process off-session payments for your subscription as you need.
You can use Stripe to place a hold on a card, but this generally doesn't apply to the use case you've described.
I found a workaround for this by first creating a paymentIntent with setup_future_usage="off_session" and capture_method="manual" to first place a hold and save the paymentMethod, and then, only after capturing this paymentIntent, creating a subscription using the newly saved paymentMethod with billing_cycle_anchor that equals your subscription's interval from now.
This way it's like your customer has paid for the first interval using the paymentIntent, but will be charged from the second interval using the subscriptions API, which allows you to cancel the hold on the first payment and not create a subscription if something goes wrong.
Currently, I am creating payments with the Square API.
https://developer.squareup.com/explorer/square/payments-api/create-payment
This charges the customer's card for the desired amount. Is there a way to authorize a payment first without charging the card?
For our system, we need to wait a few minutes for a response from our vendor to process an order. I would like to authorize a payment, then if we get an approved response from our vendor, charge the customer's card otherwise cancel the payment.
I'm trying to avoid paying transaction fees, if we are unable to fulfill an order.
You can call CreatePayment (that you linked above) with autocomplete set to false. This will authorize the payment, but not actually take the funds out yet. By default, you have up to 6 days before the payment auto-voids, so you would want to call CompletePayment whenever you intend to complete the payment (or CancelPayment if you want to manually void the payment).
On my site I'm giving users the option to save their card or not. If they choose to save it, I'm creating a Stripe customer object, and if not, I'm just saving the card token, and when it comes time to pay, if they have a Stripe Customer id then I charge that way, and if not, I charge the tokenized card.
There could be cases where a week or so passes before I would charge the card token. Would it still work, and is there anything else wrong with this setup?
Thanks for any advice.
Stripe Tokens are meant to be used within a short period of time from when they are created and should not be stored.
https://stripe.com/docs/api/tokens
If you are not charging the token immediately, I would recommend attaching it to a Customer in that scenario as well.
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.