I am implementing the Stripe payment platform using JavaScript and the PHP SDK.
I don't have any issues with the implementation itself, but I am not sure whether I have to reuse an existing PaymentIntent or it's perfectly fine to have a bunch of them created and incomplete.
I searched for this in Stripe's documentation, but I can't seem to find anything related to this.
For example, in my test account I have this:
It's all for the same transaction, because I was changing some visuals and refreshing the browser.
I am aware that each PaymentIntent has an ID, but is it recommended to add it as a query parameter and retrieve it on refreshing, or is it better to always generate a new Payment Intent.
My main reasoning is to avoid having a huge collection of incomplete payment intents.
The default integration path for Stripe today is to create a PaymentIntent first so that you get a client_secret you can use client-side to render their UI via PaymentElement. This means that if your customers decide not to pay after all, you end up with an incomplete PaymentIntent which is expected.
This is not really a problem, other than appearing in the Payments list which can be confusing. You could also write a background job daily that would cancel any PaymentIntent via you know won't be completed because the customer left and you didn't have any data to contact them to upsell them for example but this isn't really needed.
Stripe also has a beta (docs) right now (Feb 2023) that changes the default integration path. This simplifies the experience because you can render the PaymentElement client-side with specific options such as amount and currency. You'd then only create the PaymentIntent at the end of the flow
when the customer is attempting to pay. That flow limits the number of incomplete PaymentIntents since you only create them when the customer really pays. You'd still get some, for example after a decline by the customer's bank though.
Related
I am using STRIPE as my payment processor, in an REACT + nodeJS app. I already have something that already works, but I would like some feedback, maybe I'm doing something wrong.
So... I have this Redirect-To-Checkout functionality thats made available by STRIPE, basically I redirect the user to this STRIPE page where all card-data (sensitive information) is processes in order for the payment to full-fill.
What I do in my nodeJS server part is the following:
Once the user acces the redirect to check-out page, I already create a PendingOrder, with the products selected by client (Here I save some information based on client/stripe payment-intent, in order to check in later steps)
Once webhook gives me the 'payment_intent.succeeded' I check for the payment-intent information to see if it exists in my PendingOrder collection, then proceed to add in to ConfirmedOrders and remove it from PendingOrders.
I have to do this whole process because Stripe no longer gives me access to some information I require when the user is checking-out his order(such as observation that the user has based on the type of service he chooses).
Are there any down-sides to this approach or is there any other way to do it?
Thanks in advance!
You’re not really far from the best practices that Stripe recommends here. The only thing that I would change is listening to checkout.session.completed instead of the payment_intent.succeeded event. As of the latest API version, a PaymentIntent is no longer created upfront so a better to way to handle order fulfillment is to either store the Checkout Session ID (e.g. cs_live_xxx) or you could add some metadata when creating the Checkout Session and use that instead to identify the order.
I have to do this whole process because Stripe no longer gives me access to some information I require when the user is checking-out his order
As for this, I’m not sure what you mean, you can always use your app with the success page customization described here alongside webhooks. I wouldn’t use that to fulfill the order though since the user might close the page before the redirection completes which means that the fulfillment wouldn’t be done in that case. As such, webhooks are essential to order fulfillment.
Background
I am integrating stripe API into my site to take one off payments. My site will be API first on server side with a separate web and mobile front end. I am working on the API server side code. I will eventually use stripe payment pages to take credit card payments. I am trying to automate the testing of my APIs and am bamboozled by the documentation (which are thorough) as I just can't see what steps to take next.
My server side initiates a call with stripe using stripe sdk to create a stripe Session object - this contains a URL to redirect to checkout.stripe.com/pay/..., a success URL when payment is successful and a cancel URL (these I set to handle the callback).
Problem
I can automate in Postman all my API calls from Browse Products, Select Product, Place Order but the next step I am stuck. After Placing Order I get back the stripe session but how can I mimick making the payment with stripe for the session and then call my Success URL ?
When the site is complete I will redirect the UI to stripe to take payments but I am testing and completing the back end flow first.
I have copied and pasted the session URL which is returned by the stripe Session object to bring up the page in a browser and used Dev tools on Chrome to inspect Network to see which APIs are being called by stripe in an attempt to reproduce and I can see a POST to stripe.com/api/payment_methods and I can see the posted values but I can't reproduce this in Postman. Also, the documentation (https://stripe.com/docs/api/payment_methods/create) says
"Instead of creating a PaymentMethod directly, we recommend using the
PaymentsIntents API to accept a payment immediately"
Question
Which stripe APIs do I need to call to automate the flow from a stripe Session object to make a payment and then check that it was successful? Payment Methods? Make a Charge? Payments Intents? ...and how. Happy to be pointed to the documentation if you can help me understand the flow.
TIA
Checkout is a Stripe product that looks like a "box" and you can't know (and shouldn't need to know) what happens inside. It is created for the purpose that merchants won't have to think about what's being done under the hood.
Speaking from an automation perspective, you can try to reproduce the whole process but there's no guarantee it won't change in the future, and it could leave you with more problems later.
For options to reproduce:
The closest way is simulating browser filling and submission, using automated browser tools (ie Selenium). But it's not as straightforward as PostMan. Generally you would want to simulate every browser action that a human could do.
Or you can try to accomplish the same with the logs and events you receive on Stripe's Dashboard, when you test a Checkout Session by yourself. From now there are 3 requests.
And your goal is to receive the same 5 events in Webhook:
TBH I recommend to reconsider the need of this test, to see if it worth your efforts.
I am building an app to sell single item product (i.e, each kind of products listed on my platform only has a single item).
(this part has been done, and won't change) I built an in-house backend having the Rest API POST -D {"buyer_email": "abc#example.com"} url/items/{itemID}, let's call it transaction_call, which will make sure once a customer succeed the POST operation, his contact info is recorded into my backend as the successful buyer; and all other customers will fail to buy that item (at API level, transaction_call return 4xx error) because my platform can only sell one item for that product;
(this is the step that my current question is about) I am trying to use Stripe as my payment system on this platform.
I really want to integrate with Stripe as simple as possible (as I understand Stripe Checkout is the most simple / out-of-box way to implement payment). However, I am not sure if Stripe Checkout can achieve the above functionality correctly. Since the problem is a two-step problem, here is the potential issue I may run into:
Let's say, two customers A, B, get to my platform at 10:00am, both of them start purchasing process for a product, Item_a
If my system interact / call the Stripe Checkout first as the first step then call the transaction_call, here could be the problem:
A's Stripe call hits the Stripe server at 10:00:01am, and A's buying call hits my backend at 10:00:02am;
B's Stripe call hits the Stripe server at 10:00:01am, and A's buying call hits my backend at 10:00:03am;
in this way, we have already charged B but he really did not get the item
If my system calls the transaction_call first, and only if transaction call succeeds then it interacts / calls the Stripe Checkout, then
A's transaction_call succeed at 10:00:01am, but he for some reason decided not to pay (not click confirm button on the Stripe Checkout UI)
In this way, my system fails to sell the item to other buyers.
My question is whether the above reasoning process is correct, and whether I could somehow use Stripe Checkout to achieve what I am doing.
Maybe I have implement the payment functionality using Stripe Intent API to build a workflow-based payment, which I assume will be much more complex, if the Stripe Checkout way (simple wayO is really not possible.
From what I understand you have a potential race problem, where the item you're selling is very limited in quantity and you want to make sure that you can correctly notify users if it's out of stock or already spoken for.
For your first scenario, the simple solution is only invoke Stripe's API on your backend when you've received the transaction_call. For instance, you'd only create the Checkout Session once your system has identified that the item is still available. You'd then "lock" the item so that when B attempts to purchase you can immediately return an error instead of creating a payment via Stripe's API. The logic on who to charge (basically who initiated the checkout process first) in the case of a tie would then be for you to implement in your transaction_call rather than on Stripe's side.
The second scenario is a little tricker, as Checkout Sessions can't be cancelled once you create them. They automatically cancel themselves after 24 hours if no payment is made, but I doubt that you'd want B to have to wait that long if A abandons the payment flow.
Instead I think you should look at implementing a PaymentIntents integration, where you can more finely control the flow.
Your flow for scenario 2 could be:
A begins the checkout process, create a PaymentIntent on the backend, "lock" the item and start a timer
The timer (which you'd ideally show to your user) times out after N minutes if A doesn't pay
Cancel the PaymentIntent on your backend and remove the lock
B can now attempt to pay for the item, upon where you restart the process
The Stripe API has a source object that has a status field that tells you whether the payment instrument is chargeable or not.
However, in Stripe.net, all of the Source-related properties on the Customer object are of type StripeCard, which does not have any Status property. In fact, I can't see any way to retrieve a Source object in Stripe.net.
I'd like to be able to know whether a customer has a chargeable (not expired, etc) payment instrument hooked up to their account. How can I do this?
Also, does Stripe.net not allow manipulation of non-card payment instruments?
Stripe.net is a third-party library which means it wasn't built by Stripe. They haven't added support for Sources just yet which is why you're not seeing this. You can either make your own pull-request for this or report the issue on their github repo
Separately, though, you don't need to implement any of this at the moment. Cards and Bank Accounts are always chargeable by default. This status field is new and has been added for other sources such as Bitcoin Receivers but this isn't fully supported by Stripe officially just yet.
From what I understand, using the PayPal api, you can pass your payment amount by populating a hidden HTML input field which will be submitted to PayPal.
What I've got so far looks somewhat like this:
<input type="hidden" name="amount" value="60.00">
My question is - isn't this super unsafe? What's there to stop someone from changing the payment value in the element inspector for instance?
You may want to use PayPal ButtonManager API operation in order to programatically create, manage, edit, and delete PayPal Payment Standard buttons, which are the same kind of buttons that you can create from the PayPal Profile.
Hosted buttons created by this API reside on PayPal and can use all features, including inventory management; however, you can use this API to create code for non-hosted Standard buttons as well.
The button you will create from this API request will look like:
https://www.sandbox.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=19218
As you can see no values like "business", "amount" or others are visible and for this reason this would be a safe solution and personally I'd recommend it.
Back to your question "What's there to stop someone from changing the payment value in the element inspector for instance?"
We recommend to use API requests (see ExpressCheckout or ButtonManager to create Standard buttons) and Instant Payment Notifications service (IPN), which is a message service that notifies you of events related to PayPal transactions. You can use IPN messages to automate back-office and administrative functions, such as fulfilling orders, tracking customers, and providing status and other transaction-related information.