Use this authorization boundary map
Begin at the user’s first tap and end at the ledger and customer notice. Write each system on the path: app, API, queue, payment provider, callback endpoint, ledger, and support console. Mark the actor allowed to set the amount, payee, and payment state at each step.
| Item | Check or owner | Evidence |
|---|---|---|
| Customer action | Mobile or web app | Untrusted request |
| Payment API | Your service | Identity, amount, and recipient checks |
| Provider callback | External provider | Signature and event identity checks |
| Ledger write | Internal service | Atomic state and reconciliation |
Test and retest
Set safe test limits before execution: provider sandbox or approved account, maximum amount, transaction window, and stop contact. Include callback replay and timeout paths. When an external system is excluded, say which boundary was not tested and who owns the follow-up.
Evidence to keep
A scope diagram should mark data owners as well as system owners. The app controls the request it sends; the API owns authorization; the provider owns its event; the ledger owns the posted balance. At each handoff, ask whether an untrusted caller can replace an ID or state. The tester should have a safe way to create late callbacks and failed provider responses. After the run, reconcile every seeded payment ID so finance does not treat test records as unexplained exceptions.
Scope the full state change
Synthetic transfer flow: the customer submits a transfer, the app creates a pending record, the provider accepts it, a webhook marks it complete, and the ledger posts the debit. Give the tester the sandbox account, provider test key, allowed transfer amount, and exact callback endpoint. Also list the routes outside scope, such as live bank transfers and real customer accounts. Test authorization before submission, the retry path after a lost response, and webhook handling after duplicate or late delivery.
The expected invariant is one approved debit and no transfer to a payee the customer did not approve. A test may show a 200 response while the ledger still posts twice. Include the ledger and provider records in the pass check. Stop an unsafe test at the sandbox boundary. If the feature calls a shared production service, replace that dependency with a test account or obtain a separate written scope. OWASP’s transaction authorization guidance supports binding approval to the material transaction details.
Write rules the tester can execute
A scope row needs asset, environment, actor, allowed operation, maximum value, observation access, excluded dependency, and stop contact. For a synthetic transfer test, use seeded customer C-1, a provider sandbox recipient, and a cap set by the system owner. Grant read access to the test journal and queue trace so the tester can check effects. Keep test credentials outside the shareable scope sheet.
The browser supplies requested fields; the server decides which trusted customer, recipient, and amount those fields may select. The provider supplies verified payment facts. The test should try to cross each authority boundary: another customer’s recipient, a changed amount after approval, a spoofed callback, and a worker retry after a lost response. Name the expected outcome before the run so an unknown provider result is not called success.
Cleanup also needs rules. Disable seeded accounts and remove temporary test access. Reconcile seeded payments and refunds to their final results. Preserve financial journals and evidence under their retention rules; do not delete entries to make the test disappear. Record unresolved provider outcomes with an owner and next lookup. Close the run only after the system owner accepts that list.