-
Notifications
You must be signed in to change notification settings - Fork 394
Base Pay backend confirmation #825
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
✅ Heimdall Review Status
|
| }>(); // In production, use a persistent database | ||
|
|
||
| export async function verifyAndFulfillPayment( | ||
| txId: string, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typically the developer would call this type of endpoint with some user auth token of the payer (whether its the SIWE payload, or a JWT from an auth management platform). I would suggest passing a field like payerAddress to this function, and then do a validation that the sender that you get from getPaymentStatus matches the expected payerAddress, so a malicious caller does not try to send someone else's payment to fulfill their order.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good callout - I think our solve for this right now is the dataCallback context - where the orderID passes to the wallet and then directly to the backend service with the payment ID now associated with the orderID.
montycheese
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
What changed? Why?
Following some feedback from the community, adding more details to the Base Pay guide to improve backend verification and replay attack protection