3 ms·

Googler opinions are my own. As someone who has been integrating with payment processors for the past 7 years at Google, this is a great article. Many of the t

by kyrra 4y ago

Googler opinions are my own. As someone who has been integrating with payment processors for the past 7 years at Google, this is a great article. Many of the things in here are things we test when we integrate with processors. This post spends a lot of time on redirect style payments, where the user lands on some other website to enter credentials or confirm payment. This form of payment is fraught with corner cases, because the merchant and the processor are using the user's browser as the transport mechanism (ie: these are can MITM part of this flow). If you are not a super extra careful, there are so many ways to attack it. If the payloads aren't signed or encrypted, you have to worry about users messing with the content. If they are signed/encrypted, you still have to worry about replay attacks. (I've spent a lot of time thinking about redirects the last 3 years, especially with writing of our redirect spec: https://developers.google.com/pay/redirect-fop-v1?hl=en https://developers.google.com/pay/redirect-fop-v1?hl=en )

Nextgrid 4y ago
Ideally you shouldn't be using the browser as a transport mechanism. The browser should only be a means of data entry - redirect the user to the payment processor so they can enter their details, but then the redirect back should just go to a "payment status" page while your system on the backend waits for a notification (webhook, etc) from the processor in the background which would then update the record on your side (at which point the read-only status page will pick it up on its next poll and then redirect the user to the next step of whatever process they were doing). This also allows you to recover the flow should the user drop off after they've paid - you can email them a link to that "payment status" page so they can "rescue" the flow without having to start from scratch.
- afiori 4y ago
  We should essentially use the Oauth PKCE flow everywhere it is applicable
pbreit 4y ago
What if you rely on lookups or webhooks to verify payment details?

by kyrra 4y ago

Nextgrid 4y ago

Ideally you shouldn't be using the browser as a transport mechanism. The browser should only be a means of data entry - redirect the user to the payment processor so they can enter their details, but then the redirect back should just go to a "payment status" page while your system on the backend waits for a notification (webhook, etc) from the processor in the background which would then update the record on your side (at which point the read-only status page will pick it up on its next poll and then redirect the user to the next step of whatever process they were doing). This also allows you to recover the flow should the user drop off after they've paid - you can email them a link to that "payment status" page so they can "rescue" the flow without having to start from scratch.

afiori 4y ago
We should essentially use the Oauth PKCE flow everywhere it is applicable

pbreit 4y ago

What if you rely on lookups or webhooks to verify payment details?