Phase 3: stop implying kiosk/BNPL block go-live

skills/paymob-integration/SKILL.md

@@ -192,7 +192,12 @@ Before going live, validate the whole flow in sandbox using Paymob's test creden
 4. Have the merchant inspect the raw callback payload (log it) the first time, to confirm field names match what the code expects, then verify the HMAC matches manually against `references/hmac-verification.md` if anything looks off. The **Integration Wizard's HMAC validator / webhook tester** (`https://wizard.paymob.com/`) is handy for confirming your HMAC logic in isolation.
 5. Also exercise the Transaction Inquiry fallback (`references/transaction-inquiry.md`) during testing — generate an auth token, then look up the test transaction you just made by transaction ID/order ID, and confirm the merchant system can reconcile correctly if a callback were ever missed.
 6. **For Mobile SDK integrations (Phase 2B):** run through the same test cards inside the SDK's native checkout UI, on both a real device and simulator/emulator if possible, and confirm the backend callback (not just the SDK's in-app result) is what your test asserts on.
-7. Only after a full successful test run should the merchant flip Dashboard to **Live mode** and swap in live keys/Integration IDs (same code, same base URL — only the keys/IDs change).
+7. **Kiosk and BNPL can't be tested in sandbox at all — don't block go-live on it.** Sandbox has no test path for them (`references/test-credentials.md`). That doesn't hold up launch: every method uses the same Intention API, the same Unified Checkout, and the same callback + HMAC verification, so a passing card test already validates effectively all of the merchant's own integration code. The merchant enables the remaining methods in the Dashboard and goes live. Four things a card test doesn't cover — check each on the **first real transaction** for each newly enabled method, not before:
+   - **Integration ID** — each method has its own, and it must be enabled on this account in the matching mode. A wrong one fails loudly with 404 "Integration ID does not exist".
+   - **Callback field shape** — `references/hmac-verification.md` notes wallets and cards return slightly different nested shapes, and the HMAC concatenation includes the card-shaped `source_data.pan` / `source_data.sub_type` / `source_data.type`. Log the first real callback per method and confirm the computed HMAC still matches. If it doesn't, the callback is rejected and a genuinely paid order never completes — worth five minutes per method.
+   - **Kiosk settles asynchronously** — the customer pays cash at an outlet, so the callback can arrive hours or days after checkout, or never. Expect long-lived pending orders and rely on Transaction Inquiry (`references/transaction-inquiry.md`) instead of treating pending as failed.
+   - **Refunds** — kiosk and most BNPL don't support them (`references/advanced-features.md`), so don't ship a refund path that assumes they do.
+8. Once the card flow passes end to end, the merchant can flip Dashboard to **Live mode** and swap in live keys/Integration IDs (same code, same base URL — only the keys/IDs change).
 
 ---
 

skills/paymob-integration/references/test-credentials.md

@@ -45,8 +45,8 @@ Use these **only** with Test-mode keys and Test-mode Integration IDs. Never use
 
 What that means in practice:
 
-- Do **not** substitute a test card for one of these methods and record it as validated — that exercises the card rail, not theirs.
-- **A green sandbox run does not cover them.** If the merchant is enabling kiosk or BNPL, tell them *before* they plan go-live, not after: cards and wallets validate in sandbox as normal, but these have to be verified with their Paymob account manager or `support@paymob.com`. The Phase 3 exit criteria in `SKILL.md` ("only flip to Live after a full successful test run") is not achievable for these methods, so don't present a passing sandbox suite as clearing them.
+- **This is not a launch blocker.** Every method goes through the same Intention API, Unified Checkout, and callback + HMAC verification, so a passing card test already validates effectively all of the merchant's own integration code. The merchant enables kiosk/BNPL in the Dashboard and goes live — see Phase 3 step 7 in `SKILL.md`.
+- Do **not** substitute a test card for one of these methods and then report the method itself as tested. The shared integration path is verified; the method-specific parts are not, and Phase 3 step 7 lists the four to check on the first real transaction (Integration ID, callback field shape, kiosk's asynchronous settlement, and refund support).
 
 **Not confirmed either way — don't assume:** Apple Pay, Google Pay, and bank installments. (`README.md` notes bank installments are "Live IDs only," which points the same way, but confirm with `support@paymob.com` before telling a merchant whether they can test it.) Don't infer a sandbox path for any of these from the card/wallet sections above.