Skip to content

Ensure proper thing happens when payment is received #378

@Klakurka

Description

@Klakurka

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.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions