I am implementing Stripe on a website for the first time and I'm not sure the right way to do something. After the payment is successful I need to update my database before the client is redirected to the "client's account dashboard", so the dashboard shows the updated information. I thought the right way would be to use webhooks, but if the webhook takes longer to update the database then the redirection, the dashboard will show outdated info.
I found an old post with a similar problem to mine where they said there is no need to use webhooks, as Stripe API calls are synchronous and I can get "the charge object" back which indicates that the payment succeeded. It's a fairly old post so I am not sure if that's the way to go (and also, I can't find information on Stripe Docs on how retrieve the "charge object" once redirected to the "success page")
I would appreciate any help. Thanks!
*Edit: Would polling be a viable way to accomplish this? I can keep the client in the "success page" and use polling to check when the database has been updated, and then redirect.
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.
When I get an IPN from PayPal (or a similar service) to indicate a sale, they ask to :
Send back 200 OK
Send back the request body.
As you know the client can easily play with the numbers and set a price of 0, while ordering a product that cost 100$, or just get a spoof message with a fake sale.
In this case, they advice to check the IPN message on the cloud.
But at this stage the sale has been made, and if this was a hack, the seller will have to refund, and this whole scheme sounds wrong.
It seems that i can't really send 400 instead of 200 OK.
I read this How to explicitly reject an IPN request and turn out you can't really reject after you compared the payment request with your DB and found that something was wrong.
So how can i make sure the sale is authentic ?
The best solution is to use a server-side front end UI paired with two routes on your server to 'Set Up Transaction' and 'Capture Transaction'": https://developer.paypal.com/docs/checkout/reference/server-integration/ . Then you do not need IPN at all, for anything.
However, if you are going to use IPN, it is documented here: https://developer.paypal.com/docs/api-basics/notifications/ipn/
There is a verification step where you post the IPN message back to PayPal to check whether it is valid or not. This answers your question.
If what you want to accomplish is refuse the transaction due to an invalid amount or description, at this point it is already too late in the case of a sale type transaction. All you can do is issue a refund via API.
This is pertaining to the UPI Payment system in India.
I am using the sample code at https://developers.google.com/pay/india/api/android/in-app-payments to initiate Google Pay App to make UPI Payment.
And everything is working fine.
My concern is:
As all this is at the client end (mobile app), a user (say, hacker) may generate random response values and invoke the server URL to tell the server that the payment is successful. How can I prevent that? How can I ensure that the payment was actually made?
In the provided example, there is a query parameter "url", does Google's server call this URL to update the payment status?
I tried, but nothing happened (I created a page which saves the page URL (Request.RawUrl) in a text file, but on payment the page was not called).
May be Google does call this URL (and I missed something), may be it does NOT; can anyone confirm.
Repeat: My actual problem is how to prevent a hacker from fooling the server that the payment is made successfully.
Note: This is to be my first app, so banks are not ready to provide API/UPI integration.
Paytm provides an api to check transaction status, so not a problem with that.
If not a direct solution, any way around will also work as long as it prevents me from manually checking bank statements.
TIA.
We were implementing UPI payment for one of our client and realized same issue.
We haven't tried Secure Intent to solve the issue. As per NPCI Document, Signed content can be passed thru URI but does not know whether response also contains the signed info to verify its been done.. If it works, we have way to make it secure..
I would like to know if this is possible to add new payment method for Bigcommerce. I tried to contact their support without any luck. If anyone is familiar with bigcommerce and know if this is possible, i would appreciate any advice.
I already read their API docs and didn't found anything useful - only method to obtain list of available payment methods.
I already tried to signup for their partner. Without any luck.
We've done this before for a couple stores to allow clients to process payments through their own processor. The way we achieved this, is essentially through the following high-level steps:
Allow payments by Check (or similar offline method). We are going to replace this with the custom processor.
You'll notice that if you attempt to checkout via Check, that BigCommerce automatically creates the order for you, but sets the order status to Awaiting Payment. Upon submission the user is automatically sent to a 'Thank You' Order Confirmation page that contains both the Order ID and some payment instructions (such as where to send the check to).
Here's the trick -- Modify this 'Order Thank You' page to prompt the user for her or his credit card information. A simple HTML form will suffice here, performing the actual request via JavaScript.
Once you have the user's credit card data, you can then POST it to your own external server, where you would connect to and send data to whichever processor you are using. Additionally, you should make sure to send the Order ID to this program, so that you can connect to the BigCommerce API to load billing information, and then subsequently adjust the order status to either approved or declined depending on the response from your processor. Finally, you should send back some sort of response to the client to inform of the result of the charge attempt.
That's pretty much it in a nutshell. The way you integrate with the payment processor (step 4) is unique to whichever processor you are using. I hope this makes sense.
Although opinion based, I'm a huge fan of serverless technologies, and would suggest looking into AWS Lambda + AWS API Gateway. The benefit here is that you don't need to worry about creating an infrastructure or the associated concerns of security and scale. Rather, AWS Lambda allows you to simply upload your software, and allows it to be executed via an HTTP request to some defined endpoint set through the API Gateway. Lambda will scale automatically for you, and you don't need to worry about system level security concerns - only security at the application level. It's truly a set and forget setup, and a bleeding edge technology. Not to mention dirt cheap!
Implementing a new payment method is unsupported and requires hacky workarounds since we implement payment gateways via the core app. You can do this on blueprint by using an offline payment method and then using the API to update payment statuses, etc. I'd recommend using ActiveMerchant if you do wish to go down this path.