Sandbox Walk-through

Tick only what actually ran (WRK-03). Test cards are on Test Cards and Payment Methods. Run only the flows in your scope, and record the rest as not run.

1. Setup

• Readiness Preflight passes.
• Every test case is ported and passing (Test Cases and Reference Code).
• A forged callback through the public address gets a status below 400 and changes nothing. The command is on Callbacks (Partner) or Callbacks (Direct Seller).

2. Sellers (partner)

• Onboard a seller with the sandbox values and seller_phone +972501234567. MPL and public key stored.
• get-sellers shows it not approved, and your app shows the signup link.
• A seller-* callback arrives at the Default Callback URL and causes a re-read. Its body isn't trusted.

3. Checkout

• Hosted page: pay with 5326105300985846, 12/30, CVV 658, Social ID 008336174. The order becomes paid only after the query confirms it.
• Declined card 4000000000000002: nothing fulfilled, status failed recorded.
• A good card on the same sale_url after that decline: the sale ends completed, and the order is fulfilled once.
• Hosted Fields, if built: tokenize, pay-sale, and a retry after a failure uses a new sale and a new instance.
• Partner: at least one real sale callback verified as signed correctly. This proves the partner secret and the formula. With no public address, a real return URL's signature proves the same two things, but not delivery: tick this as secret and formula only, and report delivery as not proven (details).
• The same callback delivered twice is fulfilled once.
• Direct seller: stop the tunnel, pay, restart it: the scheduled re-check marks the order paid with no callback.

4. After the sale

• Authorize, then confirm with transaction_type: 40, then capture, ending completed.
• Capture on a sale still initial is refused, by your code or with error 305.
• Partial refund, then the rest with no amount. The sale stays partial-refund, and your total equals the price.
• A second authorization voided, ending voided.

5. Saved cards

• Token captured, stored encrypted, and charged again, on the sandbox.
• If you built Hosted Fields: 4000000000000036 tokenizes, then the charge declines with 20004. Otherwise record this as not run: both hosted-page forms decline that card at capture (why).
• Direct seller: the token came from get-buyer-key after confirmation, not from a callback.

6. Subscriptions

• Created without a token: sub_url, pay, callback, get-subscriptions confirms, service granted once.
• Pause, resume, change price and cancel, with your state following what PayMe reports.
• An unsigned callback alone changes nothing.

7. Payouts (partner)

• seller_wallets shown as total, releasable and the difference.
• Withdrawal refused or disabled for an unapproved seller. A new sandbox seller is on automatic plan 2, so PayMe answers 907 before it looks at approval.
• A payout as far as the account allows, re-read with get-withdrawals. A successful payout needs PayMe to set up a seller first (what to ask). Without that, record the refusal, and report a successful payout as not proven.

8. Final states

• Every sale and subscription you created re-read with a query. Any disagreement with your records is recorded as a finding.
• No partner key, secret, MPL or token in logs, responses or the browser bundle.

Then fill in the Proof-of-Integration Report.