Skip to content
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

Ensure proper thing happens when payment is received #378

Open
Klakurka opened this issue Feb 2, 2024 · 0 comments
Open

Ensure proper thing happens when payment is received #378

Klakurka opened this issue Feb 2, 2024 · 0 comments
Assignees
Labels
enhancement (behind the scenes) Stuff that users won't see enhancement (development) Improvement to the development situation
Milestone

Comments

@Klakurka
Copy link
Member

Klakurka commented Feb 2, 2024

There's a lot going on right now when a payment is received. I'll try to describe each case here:

Note that both the normal payment dialog and widget should behave almost the same.

When a payment is detected...

onSuccess (including QR code check mark and toast) should fire if:

  • Address is correct
  • Amount is correct
  • OP_RETURN (including Payment ID) is correct

onTransaction (only the function -- nothing else) should fire if:

  • Address is correct
  • Amount is NOT correct
  • OP_RETURN is NOT correct

What does it mean for an address to be "correct"?

  • As we currently only support standard BCH and XEC addresses, it just needs to match. I think we're using a library for this but if they exclude the address prefix then that's still fine.
  • When we add support for things like xpub keys and aliases, this will get more complicated.

What does it mean for an amount to be "correct"?

  • If an amount is set, it matches the amount received.
  • If an amount is not set, then any amount works.

What does it mean for an OP_RETURN to be "correct"?

  • BCH doesn't have the same level of standardization of wallets as XEC does so we should simply ignore OP_RETURN there. So when using BCH, all OP_RETURN values are fine. Have BCH ignore OP_RETURN for the purposes of triggering onSuccess #379
  • On XEC, we can simply see if the OP_RETURN matches like we do now. This should still be the case even if disable-payment-id=true. It's up to us if we want to have it accept any or even no OP_RETURN if disable-payment-id=true and op-return is not populated.
@Klakurka Klakurka added enhancement (behind the scenes) Stuff that users won't see enhancement (development) Improvement to the development situation labels Feb 2, 2024
@Klakurka Klakurka added this to the Phase 3 milestone Feb 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement (behind the scenes) Stuff that users won't see enhancement (development) Improvement to the development situation
Projects
None yet
Development

No branches or pull requests

2 participants