Payments
Every call Commerce makes to a payment provider is recorded, with the request, the response and the outcome. It is the most complete audit trail in the platform — and the only one with no screen in front of it.
Warning
The payment log is database-only. There is no back-office page for it. Reading it needs someone with database access, which makes a payment question an escalation rather than a first-line answer. Knowing what the log holds still matters, because it tells you exactly what to ask for.
What is recorded, per provider call
An append-only row per call. Nothing is updated or deleted, so the sequence of attempts is intact.
| Field | What it gives you |
|---|---|
| Order id | Which order the call related to. Nullable — a call made before an order context exists has none |
| Provider | Which provider handled it |
| Operation | What was attempted — authorise, verify, and so on |
| Request payload | What Commerce sent |
| Response payload | What came back |
| Status code | The provider's HTTP status |
| Provider reference | The provider's own transaction identifier — quote this when raising a case with them |
| Success | Whether Commerce treated the call as successful |
| Error message | Why not, when it failed |
| Occurred at | When the call was made |
Having both payloads is what makes a dispute resolvable: you can show exactly what was asked and exactly what was answered, rather than inferring from an outcome.
"The customer was charged but the order failed"
The most serious report, and the one the log is built for.
The question is where the sequence broke, and the row for the authorise call answers it:
| Log shows | Meaning |
|---|---|
| No row for the order | Commerce never called the provider. Nothing was charged by this platform |
| Row with success false and an error | The provider rejected it. If the customer's statement shows a charge, that is the provider's to explain — give them the provider reference |
| Row with success true, but no order placed | The charge went through and Commerce failed after it. This is the genuine case, and it needs a developer |
The third case is the one to escalate immediately with the order id, the provider reference and the timestamp. The other two are answerable without one.
What is not in the log
- Card details. Never stored, never logged. Commerce does not hold card numbers
- Refunds and chargebacks. Not a Commerce capability. They happen in the provider or the ERP, and neither reports back here
- Provider webhooks. Only calls Commerce makes are logged
Which provider is in play
Card payment goes through one provider per site, chosen by a setting, and non-card methods — on account, cash on delivery, bank transfer — involve no provider call at all and so leave no payment log row.
Check the setting before assuming which provider to contact. It is a per-site configuration value, and it can differ between regions.
A non-card order with no payment log rows is normal, not a missing record.
Surcharges
A card surcharge is calculated on the tax-inclusive amount being charged, because that is what the provider actually bills. It appears as its own line on the order rather than being folded into a total.
So when a customer queries a total that does not match the goods value, a surcharge line is the first thing to look for — and it is visible on the order, not buried in a calculation.