/pay. That call only pushes a prompt to
the customer’s phone (or creates a Wave checkout). The customer then approves it, the
operator confirms to Kori, and only then is your balance credited.
So every payment has three possible states:
1. Webhooks — the way you should build
Subscribe topayment_received and let Kori tell you. No polling, no timers, and it
works when nobody has a browser open.
Webhook payload
2. Read your transaction record
status. This is what you use for a dashboard,
a reconciliation job, or any time you want the answer as Kori currently knows it.
Requires the balance scope.
3. Ask the operator now
reference, not by transaction_id.
It needs no authentication — the reference is the credential — which is what lets a
hosted checkout page poll it straight from the customer’s browser.
Use this while a customer is waiting. For everything else, prefer the webhook: it
costs nothing and arrives even if the customer closes the tab.
Polling, if you must
- Poll every 3 to 5 seconds, no faster.
- Stop as soon as
stateissuccessorfailed. - Give up after about two minutes of waiting on a customer — but treat that as “still unknown”, not as a failure.
- A
500means the operator could not be reached. Retry; it says nothing about the payment.
Payments that are never confirmed
If a customer never answers the prompt, the payment stayspending and Kori marks it
expired after 24 hours. A late confirmation still credits you — expired means “we
stopped waiting”, not “the money is gone”.