An organization whose subscription list was empty could still register an app with the payment-initiation product id. The portal issued a token carrying the payment scope. The payment API accepted that token.
The consent call then accepted any valid sandbox account number in the account-selection field. There was no check that the caller owned the account. The debtor on the payment rebound to that account. Sandbox settlement completed for a credit transfer and for an instant transfer. The amounts were cents. The debtor was our own sandbox identity. A shared demo account was the stand-in for the other party.
What we proved
Product entitlement and consent ownership both failed, in that order, on the sandbox payment API. The payment object showed the rebound debtor and a settled sandbox status.
What this is not
This is not production customer money. Sandbox rails, our own organization, synthetic payments. The control-plane failure is the report: the product id was not checked against subscriptions, and the account number was not checked against the consent holder.
Why a scanner misses it
"Must be logged in" and "this is a sandbox" both look closed. The missing check is a field the spec treats as a product catalogue id, and a second field the spec treats as the payer's own account.
Buyer takeaway: Entitlement is not a checkbox in the developer UI. The token and the consent call have to enforce it, including in sandbox, because sandbox is where the integration is copied from.
