Do not open a public issue. Report privately through GitHub Security Advisories.
This library is used to decide whether money actually arrived, so the failure
that matters most is a verification bypass — anything that makes
verifyTransaction report verified: true for a payment that did not happen
as claimed. Examples worth reporting:
- A crafted SMS that causes a non-provider URL to be fetched and trusted (hostname spoofing, redirect handling, URL parsing edge cases).
- A receipt page whose parsed
amount,receiverorreferencediffers from what the page actually shows. - Account or reference comparisons matching values they should not.
- Any way to make the SMS override the receipt page, which must never happen.
Please include a redacted reproduction — never a working receipt URL or an unredacted SMS, both of which contain personal data.
While the major version is 0, only the latest published minor release
receives security fixes.
verifyTransactionchecks a single transaction in isolation. It cannot detect that the same receipt was already used; replay prevention is the caller's responsibility (persist and reject duplicatereferencevalues). This is documented behaviour, not a vulnerability.- Provider account masking means
receiverAccountmatching is deliberately lenient — two accounts sharing their last four digits are indistinguishable. Also documented, also not a vulnerability on its own.