How Online Payment Reconciliation Works

Last updated: 2026-07-09 Summary:

A customer pays on PayMongo’s hosted checkout; PayMongo then calls eKapital’s webhook to confirm.
The webhook is verified against your own signing secret, then posts the cash / EWT / receivable entry and flips the invoice to Paid.
The flow is idempotent (safe against retries), captures the fee when known, and routes cash through a clearing account until you settle it to your bank.

Online payment reconciliation is the bridge between “the customer clicked Pay” and “the invoice is Paid in your books.” eKapital never holds the money — it listens for PayMongo’s confirmation and records the accounting.

The model

Hosted checkout. From the public invoice page, the customer starts a PayMongo checkout session. eKapital computes the amount server-side (the balance due, or the EWT-net balance when the invoice is subject to withholding) — the customer’s browser never dictates the amount.
Webhook confirmation. When the charge succeeds, PayMongo POSTs an event to eKapital’s anonymous webhook endpoint. Only payment.paid / checkout_session.payment.paid events reconcile an invoice; other event types are stored for forensics and do nothing.
Tenant-aware verification. The webhook carries no login. eKapital reads the tenant and invoice ids from the event metadata, then verifies the signature against that tenant’s own webhook signing secret. A missing or invalid signature is rejected (fail-closed) — a forged event can never post to your books.
GL posting. eKapital posts the payment through the same path a manual receipt uses: it debits cash for the net, records the CWT receivable for any withheld portion, and credits Accounts Receivable for the gross — then flips the invoice from Partial to Paid.

The EWT split

When the invoice is subject to expanded withholding tax, the customer pays the EWT-net amount. The withheld difference isn’t lost — it’s booked as a creditable withholding tax (CWT) receivable, the same tax credit you’d record on a manual receipt. This is why the public page asks the customer to issue you a BIR Form 2307. See Withholding tax on online payments.

Fee capture vs later true-up

PayMongo’s processing fee isn’t always in the payment event. When it is, eKapital books it to your fee account (default Payment Processing Fees) and marks it Captured. When it isn’t, the payment still reconciles fully — the receivable clears regardless — with the fee marked Pending and trued up later from the Payouts page. AR clearing is never blocked on a missing fee.

Idempotency

PayMongo retries delivery until it gets a 2xx, so duplicates are expected. eKapital de-duplicates on the event id and on the (invoice, gateway transaction) pair: a repeat of an already-succeeded payment is a no-op. The event row is written before processing, so a downstream error leaves it replayable rather than triggering a retry storm.

Undeposited Funds → bank settlement

Reconciled cash doesn’t go straight to your bank — PayMongo batches payments into periodic payouts. So the cash lands in a clearing account first: your configured deposit account, or Undeposited Funds if none is set. When PayMongo pays out to your bank, you record the settlement on the Payouts page, moving the cash from clearing to your bank account. See Track payouts and settle to your bank.