0

Has anyone figured out a solution to this? I seem to have gotten to the same conclusion with no solution.

If I were to go the my app's checkout page, the payintent is created in the backend (explained the process below). So no after the payIntent is created, if i open a new tab and go the menu and add a new menu item, Firestore will show the new (correct) total, but since the payment intent is created stripe charges the old (wrong) total.

What I am doing is

  1. Every time the page loads, I send a GET request to my backend which verifies the identity of the user (using Firestore/Firebase).

  2. Checks if there is a payment intent (payment intents are stored in Firestore corresponding to the user)

  • A. if payIntent does not exist under user create one
  • B. if payIntent does exist retrieve payintent from stripe and check if it has status === succeeded. IF it has succeeded create a new one and if it has not succeeded update the old one. The amount for all payIntents is calculated using total in Firestore in the backend

(and of course if the users cart is empty a payIntent is not created)

  1. Send back to the frontend the payIntent.clientSecret and cart items to populate page

  2. From the front end using stripe elements and confirmPayment confirm the payment

(using ngrok the page loads in about 800-1200ms so not too bad I think)

Possible solutions are using webhooks, when payIntent is processing check and update the pricing but that seems like a duct-taped solution (if it were to even work in the first place) OR using webhooks when payment has succeeded update the payment, again seems like a duct tape solution (if it were to even work...). Possible solution:

3 confirmPayments in the backend but according to documentation that takes away 3ds authentication which is the reason I am doing confirmPayment in the frontend anyways..

1 Answer 1

0

The server should create a digital signature of the key payment fields. Alteration of payment fields would invalidate the signature.

If the digital signature is provided on the client side as well, it needs to be a full up encryption signature to prevent the client from also making the signature match. If the signature is only on the server and linked to the transaction by session ID then it could be simply a hash as it's out of reach to the client.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.