Automated bank transfer reconciliation with SePay and Casso

Why manual statement matching is always late and error-prone

At the end of the day, many shop owners download the bank statement, open the order list in Excel or a paper ledger side by side, and scan line by line to see which transaction matches which order. This is manageable with a handful of orders a day, but once volume reaches dozens of orders a day, manual scanning can barely keep up.

The biggest problem is the transfer description customers type themselves: some abbreviate their name, some forget to include the order code, and some transfer through someone else's account so the name on the statement does not match the person who placed the order. The accountant has to guess, message the customer on Zalo to check, or miss a transaction whose owner is unclear.

The usual consequences are shipping before payment is confirmed — risking a loss if the transfer never actually arrives — or holding an order too long even though the customer already paid, leaving them waiting and messaging repeatedly. Automated reconciliation solves both problems by letting software read the transaction and match the order the moment the payment notification arrives.

How SePay and Casso bring bank data into your system

SePay and Casso are both intermediary services that connect to the bank account your business already uses to receive payments, tracking balance changes in close to real time. The moment money arrives, the service calls a webhook — a URL you register in advance — carrying transaction data: amount, transfer description, time and the receiving account number.

The system on your side, usually built as an n8n workflow or part of your sales software, receives this data and processes it almost immediately, typically within a few seconds to a few dozen seconds of the customer completing the transfer. Besides webhooks, both services also provide an API to actively pull transaction history, useful for full reconciliation or when you suspect a transaction was missed due to a dropped connection.

The table below summarizes a few common plans from both providers, current as of September 2026 — free-tier limits and pricing can change, so check the official page again before signing up:

Designing the order code in the transfer description and VietQR

The key to accurate automated matching is letting the system, not the customer, fill in the transfer description. A common approach: generate a short order code, for example DH1024, and embed it in the transfer description of the VietQR code as soon as the order is created.

VietQR is the Napas 247 instant-transfer QR standard shared by banks across Vietnam, and it can encode the account number, amount and transfer description in advance. The customer just opens their banking app, scans the code and confirms — no typing required — so the order code cannot be mistyped or left out.

If you still accept manual transfers outside a QR code, ask customers to enter the order code in a fixed format at the start of the description and show clear instructions right on the payment page. Even so, some customers will still mistype or leave it blank, so the matching system needs a fallback for this case instead of relying on customers to get it right.

Matching rules: exact amount, partial payment, overpayment, duplicates

A reliable automated reconciliation system needs to handle each situation explicitly instead of only matching the exact amount and ignoring everything else:

• Exact match: the order code is found in the description and the amount equals the order total → automatically mark it paid, with no human step needed.
• Partial match: a customer pays a deposit or pays in several instalments for the same order code → add up the amounts received and only close the order once the total is reached.
• Overpayment: the amount received is larger than the order total → still mark it paid but record the difference separately for a refund or offset against a later order, rather than treating it as extra income.
• Duplicates (idempotency): every transaction carries a unique transaction ID issued by the bank — the system stores this ID and ignores a webhook that resends the same one, preventing the amount from being counted twice when SePay or Casso retries after a temporary connection drop.
• Late or unmatched: a transaction that cannot be matched to any order, because the customer mistyped the code or paid before the order existed → route it to a list for manual review with the full amount, time and original description, never guess and assign it to the closest-looking order.

Webhook security: never trust an amount sent from the client

Because a webhook is a public URL, anyone who knows the address could send fake data to fabricate a transaction if the system does not verify where it came from. The rule is non-negotiable: payment confirmation must be decided by the server based on verified bank data, never by the customer's browser or app simply reporting 'I already paid'.

SePay lets you choose webhook authentication with HMAC-SHA256, an API key or OAuth 2.0 right when you set it up — pick one of the three rather than leaving it unauthenticated. Casso attaches a secret key in the Secure-Token header on every webhook call; your system must compare this against the key stored on your server before processing any transaction.

• Always verify the signature or secret key before reading the webhook payload; never process a request whose source has not been authenticated.
• Never trust an amount or payment status sent from the customer's browser or app; the real amount always comes from verified bank data delivered through the webhook.
• Never expose account balances or bank account numbers in logs or public interfaces that outsiders could view.

Notify Zalo the moment money arrives, log it to Google Sheets automatically

Once a transaction is matched, the workflow should notify both the seller and the customer on Zalo almost instantly: the seller knows to prepare shipping, and the customer knows the order is confirmed so they do not need to ask again.

In parallel, each transaction should be written as one row in a Google Sheet acting as a payment ledger: order code, amount, time, original description, and match status. This ledger replaces opening the banking app to hunt for an old transaction, and it can be shared with an accountant without giving them access to the real bank account.

An end-of-day reconciliation report to catch what slipped through

Webhooks work reliably most of the time, but the network occasionally drops a transaction. It helps to add a step that calls the API to fetch every transaction for the day and compares it against what was logged, catching anything missed instead of relying on the webhook alone.

At the end of the day or week, a short report sent over Zalo or email should state: total amount received, number of orders matched automatically, number of orders waiting for manual review, and number of unresolved overpayments or underpayments — so the owner knows exactly where to look without reading the entire ledger.

Checklist before turning on automated reconciliation

Before running it on real orders, check every item below:

• The SePay or Casso account is linked to the correct bank account used to receive payments.
• Every order generates a unique order code embedded in the VietQR code before it is shown to the customer.
• Webhook authentication is turned on — HMAC-SHA256, an API key or Secure-Token — never left unauthenticated.
• All four situations are handled: exact match, partial match, overpayment, duplicates.
• Transactions that cannot be matched to an order code have a dedicated place for manual review, with no guessed assignment.
• At least one real transaction of a small amount has been tested before relying on it for all orders.