Gateway API or settlement file — which you actually need

When a merchant asks whether a gateway "has an API", the honest answer is that the question is slightly wrong. Malaysian gateways offer a range of access methods, and the transport matters far less than what the data contains.

A well-structured file processed automatically will close your books. A modern API returning daily totals will not.

The four levels of access

Ordered by what they let you finish, not by how modern they look.

Portal download. A human logs in and exports. Works, and puts a person in the loop every cycle forever. Fine at low volume, a permanent tax at any real volume.

Scheduled file. Delivered to you, or collected from a location, on a cycle. No human required. Whether it is enough depends entirely on the contents.

Reporting API. Query settlements and transactions on demand. Convenient, and no better than a file if the fields are the same.

Full API with webhooks. Query on demand plus notifications as things happen. The most capable, and worth the extra engineering only if the data underneath justifies it.

Most merchants assume level four is the goal. In practice level two with good data beats level three with poor data, comfortably — see why integration depth beats feature count.

What the data has to contain

This is the real question, and it is answered by looking at a sample rather than reading a specification.

Transaction-level records, not daily summaries. A total tells you nothing you can match.

A reference that joins to your order. Without it, everything downstream is composite matching — see the gateway reference that joins everything.

Fees itemised per transaction, not as a batch total. A batch fee makes per-order margin impossible.

Payout grouping. Which transactions made up which payout, so a bank deposit can be decomposed.

Refunds, chargebacks and reversals, identifiable as such and linked to their originals.

Holds and releases, shown explicitly rather than as an unexplained difference — see payment gateway holds and reserves.

A file with all six closes the loop. An API missing two of them does not, regardless of how pleasant it is to call.

The test to run during evaluation

Ask for a sample settlement file or API response covering a real week, with a payout in it. Then try to answer one question:

Can I take one bank deposit, identify every transaction inside it, and account for the difference between their gross total and the amount that arrived?

If yes, the access method is sufficient and the rest is engineering. If no, you have found the manual work you will be doing indefinitely, before signing rather than after.

An hour on a real file is worth more than any amount of specification reading. It is the same test that applies to accounting software generally — see how to evaluate AI accounting software.

Practical differences that matter

Availability timing. When does the data appear relative to the money? A payout arriving before its report is normal and needs designing around — see when the payout arrives before the report.

History depth. How far back can you retrieve? This decides whether a migration can bring prior periods with it, and gateways vary widely.

Amendments. What happens when a settlement is corrected? A file that is silently republished with different contents will break a naive import, and knowing whether that happens changes how you store what you receive.

Rate limits and quotas on an API, and delivery guarantees on a file. Both fail occasionally; what matters is whether you can tell.

Why webhooks are not the whole answer

Where a gateway offers notifications, they are useful for currency and insufficient alone.

Delivery is not guaranteed indefinitely — endpoints go down and events are missed. Arrival order is not promised. Duplicates happen, so every handler must be idempotent, producing the same result whether an event is processed once or three times.

The workable design is notifications for freshness plus a periodic full pull to catch what was missed. That applies to Shopify's own webhooks equally — see what it takes to build a Shopify connector.

Common questions

Does a payment gateway need an API for automated reconciliation?

No. What matters is whether the data contains transaction-level records with a reference joining to your orders, fees itemised per transaction, payout grouping, and identifiable refunds and holds. A scheduled file carrying all of that reconciles completely, while a modern API returning daily totals cannot, so the transport matters far less than the contents.

What should you ask a gateway for during evaluation?

A sample settlement file or API response covering a real week including a payout, then test whether you can take one bank deposit, identify every transaction inside it, and explain the difference between their gross total and the amount received. If that cannot be done on the sample, it will not be possible in production either.

Are webhooks enough on their own?

No. Delivery is not guaranteed indefinitely, arrival order is not promised, and duplicates occur, so handlers must be idempotent. Notifications keep data current but need a periodic full pull alongside them to catch anything missed, which is true of both gateway webhooks and Shopify's own.

What is most often missing from gateway data?

Fees itemised per transaction rather than as a batch total, and explicit payout grouping showing which transactions made up which deposit. Without the first, per-order margin cannot be calculated; without the second, a bank credit cannot be decomposed, and the reconciliation stops at exactly the point where it would have been useful.

Related: how to read a payment gateway settlement report · the gateway reference that joins everything · what it takes to build a Shopify connector