so i've seen some question about this subject but no good answer
after creating a paypal payment via paypal api, the client is being redirected to paypal for payment approval
the payment object also gets a "approved" and "cancelled" urls so that paypal could let my server know what course of action took place within the client's approval process
if the client has cancelled the payment, the http request being sent from paypal looks like this:
/customerCancelled?token=EC-32W183225U612050A
when "customerCancelled" is a get method in my server of course
what paypal claims should be done here is just to cancel the payment in my DB because they already cancel it on theirs
the problem is here - what the hack is this token? its not the paymentID (which is the primary key of the payments in my database)
how does it help me identifying the payment object that was canceled?
it takes a lot of time until paypal answers questions.. so if anyone here has got a clue that would be helpful
thanks
I know this is old, but i dont think the Paypal .net API has improved much since this bug, and neither has the docs.
I noticed that the token you require was on the "approved_url"
I stripped it out, and saved it, so if the cancel is returned, you can look up your order via that token.
I have discovered it. When you enter the cancel URL first you have to ask for access token (if you dont have it stored), then get the payment information (here you can see) and the response contains a cart value, the cart value is same that the token without EC-, I mean, if cart value is 1234567890 the token you have is EC-1234567890.
When you create the payment store in your database (or elsewhere) the payment id, cart value and the final token. Then on cancel you search the cart value in your database and you obtain the Payment ID.
Did I explain?
Related
I am currently integrating Stripe Elements into my ReactJS app. What I am developing is a system in which my users can upload an image to display as an advertisement on my web app for 30 days. This means that a payment needs to update a row in my database with a new expiration date. We are also having the users manually renew each expiration period so we are not using subscriptions.
From what I understand, the flow is as follows for a first time customer:
User goes to the advertisement upload page
The user submits the advertisement form. Client sends POST request to my API server and creates payment intent with NodeJS Stripe SDK
Advertisement is saved into DB with an expiration date of null.
Payment Intent ID is saved to relationship table associating it with the banner
advertisement
Payment Intent secret is sent to client with status OK
Client Secret is given to Elements to show and handle the payment form
Stripe sends the event to my webhook endpoint with Payment Intent ID.
Use Payment Intent ID to find which banner advertisement should be updated with new expiration date
From what I've read on the docs, this flow should work. If anyone notices issues, please let me know!
My question is: can I show the user their next advertisement expiration date right after their purchase? Or do I need to show them "Pending" until my webhook receives the event?
Thanks in advance for any answers or advice!
You can, but whether or not you should is primarily a business decision for you to make based on the customer experience you're hoping to achieve.
It will likely be influence by the exact integration path and payment method options that you're offering. If you're going to use the Payment Element with delayed notification payment methods, then you may want to wait for confirmation that the payment was successful.
https://stripe.com/docs/payments/payment-methods#payment-notification
But if you're using the Card Element(s) and only accepting cards, then part of the response from confirmCardPayment is the Payment Intent if the payment was successful so you have a more immediate indicator of success.
https://stripe.com/docs/js/payment_intents/confirm_card_payment
In the stripe documentation, it says:
So in this case, the checkout page goes to the success or failed page on my frontend.
I use the backend to track the payment status so that we can monitor the transactions in the admin portal, and the above approach seems dangerous to me.
When checkout is successful, it redirects the window to the success url. This means I have to call the backend API in the success page to update the payment status. However, the stripe is the source of truth about the payment status, and the status update on DB should come from Stripe, not come from a frontend page. At the very minimum, if a user refreshes the success page, it would have called the API again and again which is bad. Also, it is about "a user says I paid successfully" v.s. "Stripe says they paid successfully".
I tried the Stripe webhooks, but in the webhook data object, there is no information that I can use to link it to the sessionId that is generated from creating the checkout session, but the session id is the only tracking id I can get from Stripe about a payment.
What's the best practice, if Checkout is the only solution, to securely update my database?
You have 2 options:
Rely on webhooks. The checkout.session.completed event will describe a Checkout Session which contains its ID, which you hopefully saved when you created the Session earlier so you can link the two together.
Retrieve the session ID from the success URL once the payment is complete and retrieve the Session on your server, then check the Session's payment_status. This way your server can verify if the payment was actually completed or if someone just managed to guess the URL of your success page.
Stripe doesn't recommend only doing option 2, as it's very possible that users close the browser tab or window before the redirect to your success page can happen, resulting in a possible loss of payment confirmation. You should always use webhooks instead to guarantee your purchase fulfillment logic correctly fires.
You can get Stripe Payment status or session Details by session_id on asp.net core || .Net 5
var service = new SessionService();
Session session = service.Get(yourSessionId);
// You can track :-
session.Id;
session.PaymentStatus; // Paid or Unpaid
session.Status;
session.Mode;
//And more
I am using Stripe for payment for the first time. While clicking on Pay button when we enter email, card number, date and cvc, I get an error message which asks me to activate my account. I learned that it takes all this information and returns a token which we can save in the database. How do I get a token in return?
thanks for thinking of using Stripe! I work on Support there and can help.
If you're getting that error message about activating your account, it's probably because you're using live keys but don't have a live, active account yet. If you email into Stripe support using the email address associated with your Stripe account, I could look into this for you further (e.g., looking at your logs and status).
As for the token, the token is a short-term representation of the customer's credit card information. You wouldn't need to store the token in your database. You should instead use it to process a charge, or create a customer, and then ignore it (because, at that point, the token will have been consumed).
For more, see this page in our docs:
https://stripe.com/docs/tutorials/charges
Cheers,
Larry
I'd like to set up a part of my site as a 'restricted' area that you need to pay via Paypal to access. Can anyone offer some advice on how to do this? Ideally I'd like to have a 'subscribed' value in my database that I can check when people attempt to access the site to check if they have subscribed. I've started looking into IPN which might be the way to do it?
Many thanks
I'm working on a new store that will integrate with PayPal. From what I've read, yes, IPN seems like the way to do it. Have a Subscribe button, and when you receive an IPN message that indicates successful payment, update the user's 'subscribed' field. I think IPN also sends a message when their subscription runs out.
I am looking at the Moneris Payment Processing and their Direct Post method. For the life of me, I can't figure out how the security on it works.
As best as I can tell it does this:
Web User comes to my site. They fill out their credit card information (https).
I show them a summary in a form. When they hit submit they go to Moneris (POST) - including my ID, credit card info, and a custom Transaction ID.
Moneris processes the transaction and sends them back to my site (as a POST)
If they arrive on failed.php or whatever URL you specify, the transaction failed. Else:
If they arrive on gotyourmoney.php then the transaction seemingly worked. Time to validate. (included in POST vars is a Unique ID for the transaction, date/time stamps, response_code (got money, didn't get money) and a few other miscellaneous items.
I redirect the user back to the moneris site with another POST. I include my ID again and the Unique ID returned in step 5 to verify the transaction.
User is redirected back to gotyourmoney_verified.php as a POST again with the unique ID, Transaction ID, and response_code.
What I can't figure out is this:
No where does there seem to be any information that I can validate that the web user can't just make up. Even though it is an https connection I'm trusting the user to pass all information. They could immediately go to the gotyourmoney.php page and never even go to the moneris payment gateway. They can just make up the ID's. When I send them back to moneris for the transaction verification, again they could just post a made-up response to my site.
What am I missing?
The Transaction Verification feature of DirectPost can be used to prevent spoofing.
Here's how it works
A customer enters their credit card information on your site and the information is sent to Moneris for processing
Moneris processes the transaction and sends the transaction result to your site
If transaction verification is enabled then there will be a special field in the transaction result called a "transaction key"
Then to verify that the transaction wasn't spoofed, your site would send the transaction key in a transaction verification request to Moneris
Moneris would then verify the transaction using the transaction key and respond with a result that lets you know if the transaction was spoofed
The Integration Guide for DirectPost has all the details on how to implement the Transaction Verification feature and can be download at http://developer.moneris.com (free registration required).
In addition to Transaction Verification you can also setup a referrer URL. If a referrer URL is setup then Moneris will verify if the transaction is coming from an allowed URL. It's possible to circumvent the referrer URL feature but having a referrer URL enabled is still useful as part of a defense in depth strategy because it makes it that much harder to spoof a transaction.
Indeed since all of those things go through the client, they can easily be spoofed. And the Moneris documentation doesn't tell you this. You need some sort of server-to-server step to be sure that everything is in order.
I would suggest doing a preauthorization using the hosted pay page and then doing a capture with the PHP API. Since you're doing the capture server-to-server, any attempt to spoof by the client will just result in a failed capture.