# Post-Integration Self-Check

> Heads-up list for the merchant after integration: items that sandbox / local environments cannot cover, and items where sandbox does NOT judge business correctness. The merchant should pay attention to these and decide when and how to verify each.
>
> Scope boundary:
> - **This document** = sandbox-unreachable capabilities + business-logic correctness (action items / reminders).
> - **The online [Integration Checklist](https://cdn.marmot-cloud.com/page/antom-integration-doc/references/checklist.md)** (referenced from SKILL.md `Integration Validation`) = compliance audit of regulatory clauses. The two are complementary, not overlapping.

---

## 1. Capabilities sandbox / local cannot verify

| Item | Why sandbox cannot verify | What the merchant must do |
| --- | --- | --- |
| `notify_url` public reachability | Antom sends notifications from public network; local server cannot be reached | Deploy to a public HTTPS domain, or temporarily use a tunneling tool. Re-verify with the real production domain before launch. |
| Notification retry + idempotency | Sandbox does not actively retry against local environments | Manually replay the same notification (re-POST identical body) and verify the business DB records the order only once. |
| Robustness of signature verification | Sandbox notifications always carry a valid signature; cannot exercise the "forged signature" branch | In unit tests, craft a forged signature and verify the service rejects it. |
| Fallback query when notification is missed | Sandbox does not simulate "notification lost" | In an offline test, disable the notification receiver and verify the service falls back to `inquiryPayment` on schedule. |
| Production payment-method activation status | Sandbox does not require activation, so its presence proves nothing about production | Confirm every payment method is **Active** in Live mode. Full activation flow (entry, required materials, review time) lives in [Account & Credentials Onboarding Guide](https://cdn.marmot-cloud.com/page/antom-integration-doc/integration-guides/onboarding.md) → `Going live`; do not duplicate it here. |
| Production gateway / ClientId / key switching | Same code, different config between sandbox and production | Grep the codebase for sandbox host residues; verify config-center / KMS switching with a dry run before cutover. |

---

## 2. Business logic correctness sandbox does not judge

| Item | What the merchant must do |
| --- | --- |
| Order state machine | Draw the transition graph (pending → paid → shipped / refunded). Ensure no duplicate shipment, no duplicate refund. |
| Payment-result persistence consistency | The async notification and `inquiryPayment` results must converge to the same conclusion; if they conflict, define which one wins and document it. |
| Cumulative refund amount check | Sum of partial refunds must not exceed the original payment amount. |
| Duplicate payment prevention | Before a payment result is confirmed, the same order MUST NOT be allowed to initiate another payment. |
| User-facing UX on abnormal paths | On network timeout or missing notification, the front-end copy should guide the user to wait, not to retry blindly. |
|Settlement currency correctness|Verify settlementCurrency matches the contracted currency. Omit if only one is contracted; required if multiple. Check at Dashboard → Finance → Overview (https://dashboard.antom.com/global-payments/finance/overview) in **Live mode** before going live. If multiple currencies, ensure `settlementCurrency` is set correctly in production config.|

---

## Suggested output style

When wrapping up an integration session, surface both tables to the user as a reminder list. For each row, you may optionally append:

- **TODO** — user has not yet verified; suggest a concrete action.
- **VERIFIED LOCALLY** — user reports already done; note briefly how.
- **N/A** — not applicable to the current integration scenario.

This is a soft reminder, not a sign-off. The user decides whether and when to act on each item.