Skip to main content
Webhooks are the primary way you learn a charge’s outcome, but every integration needs a way to ask “what happened to order X?” without depending on a notification having arrived. Two endpoints cover it.

​
Look up by your reference

GET /charge lists charges and accepts a reference filter, so you can find a charge from your own order number without storing the PayChoice ID.
​
string
Return only charges whose reference matches.
​
datetime
Start of the window, UTC.
​
datetime
End of the window, UTC.
​
integer
default:"0"
Page to return.
​
integer
default:"100"
Items per page.
​
uuid
Required for agency credentials.
from_item / to_item are the positions of the first and last item on the page; total_count is the number of charges matching the filter.
On this endpoint status_code is an integer and the surcharge fields are fee_applied / fee_amount / original_amount — different from the create-charge response. See Charge status.

​
Retrieve by charge ID

Returns the same charge object under a charge key. A charge that doesn’t exist returns 404.

​
A reconciliation loop

A simple, robust pattern:
  1. When you create a charge (or hand off to the Widget), record your reference with a status of pending.
  2. On each verified webhook, update the record by reference (or by id once you have it).
  3. On a schedule — every few minutes is plenty — list charges for references still pending after a reasonable window and update from status_code.
  4. If a notification was missed, re-send it with Retry Notification so your webhook handler stays the single place that fulfils orders.
Bank charges can legitimately sit at Processing (9) for up to three business days, so don’t treat that as a failure.

​
Next

  • Tokens — keep a payment method on file.
  • Refunds — when an order is cancelled.