Testing and go live

Run these before asking for an active merchant:

1. 1

   Catalog

   Create Fiber Internet with Starter, Plus, Pro, and Flex, then add Pro Annual.

2. 2

   Isolation

   Create Abel, subscribe HUB-10042 to Plus, confirm another merchant's key cannot read the account.

3. 3

   Usage validation

   Subscribe a second account to Flex, post 12.5 GB. Confirm negative quantity and zero-length period fail.

4. 4

   Advance bill timing

   For Plus, bill appears around period start without usage; due_date is period start.

5. 5

   Arrears bill timing

   For Flex, bill appears when the period ends after the usage report; due_date is period end.

6. 6

   Checkout + idempotency

   Initiate, open checkout_url, handle bill:created / bill:processed / bill:paid. Deliver bill:paid twice — ledger posts once.

7. 7

   Manual receipt path

   Submit → reject with reason → submit again → approve. Bill paid on approval, not on submit.

8. 8

   Auth negatives

   Initiate with no key, with not-a-pair, and with a key that cannot take payments. Expect 401 or 403.

When the merchant is active, switch the server to the production key. A test key against an active merchant returns HTTP 403.

Set a production callback_url on the product before the first live subscription. Update with PUT /api/v2/biller/products/{product_id} if the sandbox URL is still stored.

• The process that holds the secret is a server, not a client.
• Sandbox tests above passed, including a duplicate bill:paid.
• The production key is configured and merchant status is active.
• callback_url is HTTPS and returns 2xx quickly.
• Arrears products have a job that posts usage or manual_amount before the period ends.
• Starter, Plus, Pro, and Pro Annual are FIXED; finance expects due date at period start.
• Flex usage is posted before the month closes.
• Receipt approval (not submit) is what your ledger treats as collected.
• Logs store payment ids and event names — never the API secret.