Payment lifecycle

sequenceDiagram
    autonumber
    participant SP as Service provider
    participant U as UniPay
    participant PP as Payment processor
    actor C as Customer

    SP->>U: Publish bills
    C->>PP: "Pay my bill 4444INV0009"
    PP->>U: Look up the bill
    U-->>PP: Bill, amount payable, accepted currencies
    PP->>C: Show what's owed
    C->>PP: Confirm
    PP->>PP: Debit the customer
    PP->>U: Report the payment (with its rrn)
    U->>U: Record it in the ledger
    U-->>PP: Payment Saved
    PP->>C: Receipt
    SP->>U: Read the payments feed
    U-->>SP: New payments since last read
    SP->>SP: Post to billing system

Steps	Who	What happens	Guide
1	Service provider	Publishes bills, and republishes them as they change.	Publish bills
2–5	Payment processor	Looks the bill up and shows the customer payableNow.	Look up a bill
6–7	Payment processor	Takes the customer’s money in its own systems. UniPay isn’t involved.
8–10	Payment processor	Reports the payment. UniPay checks it, records it, and answers.	Pay a bill
11	Payment processor	Gives the customer their receipt — only after UniPay has confirmed.
12–14	Service provider	Pulls new payments and posts them to its billing system.	Collect payments

Things that are easy to get wrong

• Report a payment only after the customer has been debited, and give the customer a receipt only after UniPay confirms it.
• The order is fixed: debit, then report. If you can’t reach UniPay after debiting, keep retrying with the same rrn — see Idempotency and retries. Don’t reverse the customer’s debit because a report timed out.
• UniPay doesn’t push. Service providers read the payments feed on their own schedule; nothing calls them back.
• Money moves separately. Recording a payment in UniPay is not a bank transfer; settlement to the service provider’s bank account follows. A processor that pays providers directly reports each transfer as a day settlement.
• A recorded payment is never edited. If one shouldn’t stand, it is reversed.