Integrate 1BILL

First: inspect and classify

• If an integration exists, identify its exact 1LINK product, API/catalogue version, organization role, environment, endpoints, authentication/signing scheme, and implemented flows. Repair the current design with minimal disruption.
• If no integration exists, design it using the project's language, framework, data model, security, logging, job, and testing conventions.
• Never invent request fields, response codes, signatures, encryption, URLs, credentials, prefix rules, PSID length, or timeout behavior. Obtain them from the merchant's current 1LINK sandbox/certification documentation.

1. 1LINK member bank or non-bank initiator consuming 1BILL APIs;
2. billing entity exposing or connecting billing data for collection;
3. government or institutional collection through an approved partner;
4. merchant actually seeking 1GO/Raast P2M or card checkout rather than 1BILL.

Confirm the product

Workflow

1. Obtain the latest 1LINK developer-portal product selection, private API specification/OpenAPI file, onboarding pack, credentials, rate limits, test data, certification cases, and production cutover instructions.
2. Record the exact catalogue/API version and compare it with any existing implementation before changing code.
3. Define bill category, biller prefix/reference rules, amount rules, expiry, duplicate-payment policy, payer-visible fields, and internal invoice lifecycle.
4. Model inquiry, payment, void/reversal where contracted, payment-status inquiry, reconciliation, and exception handling as separate idempotent operations.
5. Keep the server authoritative for bill references, amounts, expiry, paid status, and settlement. Never trust a client screenshot or client-reported result.
6. Store correlation identifiers needed to trace the application record, 1LINK request, channel transaction, status inquiry, settlement, and support case.
7. Protect credentials and message integrity exactly as specified in the current certification pack. Reject invalid, replayed, unauthorized, or malformed requests safely.
8. Test duplicate, delayed, missing, reversed, timed-out, and ambiguous transactions—not only successful payment.
9. Complete 1LINK sandbox testing and formal certification before production. Change only approved environment configuration during cutover.

Reliability rules

• Treat timeouts and transport failures as unknown outcomes until status inquiry or reconciliation proves the result; never retry payment blindly.
• Make bill inquiry read-only and payment posting idempotent under the contracted unique transaction identifiers.
• Enforce unique constraints for external transaction IDs and internal bill/payment references.
• Use transactional state changes and an append-only audit trail for financial events.
• Do not mark a bill paid only from the user's return screen, screenshot, SMS, or frontend request.
• Reconcile transaction records with 1LINK/settlement reports and surface mismatches to operators.
• Keep human-readable support data such as channel, reference, amount, date/time, and trace/transaction identifiers without logging secrets or full sensitive payloads.

Reference routing

• Read references/product-and-api-surface.md to choose the correct 1LINK product and understand publicly confirmed 1BILL operations.
• Read references/implementation-workflow.md for state modeling, inquiry/payment/status/void flows, PSID/reference UX, and certification.
• Read references/security-and-reliability.md before implementing authentication, financial state, retries, logging, reconciliation, or production rollout.
• Read references/research-notes.md for dated official sources, public-doc limitations, recent community reports, and what must be re-verified.

Verification and output