I am quite new to PayPal rest API and wanted to provide user with a way to retry payment option in case user does not continue or cancel from the PayPal approve URL. Should I create a new order altogether and get a new approve URL or is there a way to retry payment for an old order in 'CREATED' OR 'APPROVED' state?
An order is valid for 72 hours from the moment it is created, and for 3 hours once loaded in a PayPal checkout for approval.
If a user abandons it and is going to restart their checkout on your site, it's generally best to forget about the old order and generate a new one. You can specify a unique invoice_id for orders to prevent any accidental duplicate payments (by default the PayPal account will only allow one completed payment per invoice ID)
Rather than redirecting away from your website to PayPal for approval, for modern websites it's best to keep the user on your site, and have them approve the payment in an in-context experience/lightbox, which also has the option of expanding a credit card form right within your website. See the demo at https://developer.paypal.com/demo/checkout/#/pattern/server
Related
for my subscription based product I want to have a possibility to subscribe and enter payment details at once with stripe and struggle with that with the api.
In https://stripe.com/docs/billing/subscriptions/build-subscriptions?ui=elements I see an option to create a subscription with payment_behavior='default incomplete' and then enter the details to confirm the payment intent. So far so good. However if I create the subscription like that even before the customer confirms payment details stripe already generates an invoice which is not really what I want before final confirmation by customer.
Options I see:
create setupintent, have this filled by customer via elements and then have the customer subscribe. Technically works nicely but for a sales and customer perspective is not good as it has two steps thus probably reduces conversion.
create the subscription in the background before final subscription confirmation by customer and use the clientsecret of it to pass back to browser and then have customer enter his payment data and submit that and finish the setup of subscription and payment info. Technically works - however I realize that when I create the subscription to get the clientsecret to pass to elements before the customer enters his payment data and confirms the subscription the subscription is not only created but an invoice too - which would be really, i.e. an invoice created before customers really confirms the contract
create setupintent and submit it via elements and in metadata of it add the info of product that customers wants so that when the paymentmethod gets created and I get webhook event I do the booking of the product given in metainfo. May however mean the customer gets to success page but the webhook has not notified yet and thus the customer is not really subscrubed at the point in time but gets a success message he is
same as 3 except do not pass info via metadata but via successUrl parameters which refers to and endpoint at my backend which upon being called after setupintent was setup will do the subscription and then redirect to my frontend which shows success page. That seems like a error prone workaround however.
Create a workflow which is a 2 step sign up and asks for paymentinfo, sets that up and then brings customer to a final confirmation page where the submit triggers subscription creation. Seems a bit complicated from a user flow, but so far probably the best option?
Any better options?
Cheers
Tom
ps: Interestingly enough on discord stripe support told me #2 is the way to go - find it hard to believe ...
As far as I know, there isn't a workaround for this unfortunately. It is just how Subscriptions API is designed by Stripe. You can learn more about that here where they talk about "how subscriptions work".
Consider the following course of events:
A user selects one of multiple subscription options on my website and clicks the "pay" button.
They're redirected to the Stripe Checkout page but don't complete the payment yet.
They somehow manage to get back to the page where they select the subscription while keeping the Stripe Checkout page open. (I know this is somewhat contrived but technically possible.)
They choose a different subscription option and click on "pay" again.
A second checkout session is created and another Stripe Checkout page opens.
Now they complete payments on both checkout pages.
How can I prevent this? Is there a way to cancel a checkout session? When I create a checkout session for a subscription, I don't receive a payment intent that I could cancel. There also doesn't seem to be a way to cancel checkout sessions directly.
I don't know of a way to prevent the scenario you described as the customer in question is explicitly deciding to pay you twice for two different subscriptions.
That said, if your use case requires a customer to have only a single Subscription you could add logic on your end that would do the following:
Set up a webhook endpoint to listen for customer.subscription.created events.
Whenever a new Subscription is created list the Subscriptions belonging to the Customer.
If the Customer has more than one active Subscription cancel the newest one(s) and refund the associated payments. You may also want to send the customer an email letting them know what happened.
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 have a question to ask about payment strategy with Stripe Checkout API. consider following scenario
A vendor published 10 products(apples) for 5$ each in a marketplace
A customer wants to buy 8 of them, and he fill the details and click checkout button
( stripe checkout page comes)
But customer waits idle for 1 hr without completing the payment ( just looking at the UI)
Mean while someone else buy all 10 apples
first customer doesn't know about that because he is already in final payment page.
And he pays 40 $ for 8 apples
Transaction is fault because no apples left to deliver.
I am trying to integrate Stripe payment gateway to my marketplace platform and I could not find a solution for this kind of scenario.
Is there any feature in Stripe to handle this ? Like session timeout period ?
Or What is the standard way to handle this ?
Appreciate your help.
I don't know if this is still relevant!
But I had the same problem before. What I did is I start managing the sessions from the application side. So I have a stripe sessions table and I have a timeout, and status of the session. Also, I have a purchase table with a status that could be pending if the user didn't pay yet. So I can update the items counts in the real store.
This is the scenario I have implemented. It might help you or anyone who is thinking of this problem. Maybe there is a more perfect scenario but this works for me :v:
User presses on pay
The application makes a POST request to your application create session endpoint, with all needed information
In the backend, check if this user has an active session with the same information, if yes just redirect him to that active session id. If no just create another stripe session, record its info in your database and redirect the user to the new session id
Then add a purchase record with the amount/quantity the user is attempting to get (with status = pending) and the session id you have. Then update the items page and subtract this quantity...
Create a webhook with that session id. So you can know if it is done or not (you have to have an endpoint that accepts session ids)
You check your active sessions periodically (cronjob) if a session is too old (like one hour) you just delete it and delete the pending purchase then update the items count in your store back to the actual count.
And when stripe calls your webhook with the required events, you can now set the session status and purchase status to done (Don't forget to check the call signature for more security)
I hope this will help you.
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