Reconciliation models
Efficient reconciliation is critical for managing virtual account transactions. LocalPayment offers four reconciliation models, each suited to different business needs.
Localpayment offers multiple Virtual Account reconciliation models to accommodate different operational and regulatory needs. Depending on your business requirements—such as whether you accept one-time or recurring payments, your ability to reconcile transactions manually or automatically, and the granularity you need for identifying payers—you can choose the model that best fits your workflow.
1. One Virtual Account per Transaction (TM - Transaction Model)
In this model, a unique virtual account is generated for each individual transaction. This means that every time a customer makes a payment, an exclusive virtual account is assigned to that specific operation.
Advantages: This offers the highest level of granularity in reconciliation. Every payment received into one of these virtual accounts can be immediately linked to a specific transaction, facilitating detailed tracking and complete automation of reconciliation. It's ideal for businesses with a high volume of unique transactions. Once the payment is received, you are able to delete or disable the virtual account.
Ideal for: E-commerce platforms, per-order invoicing services, crowdfunding, or any business where each payment must match a specific item or service.
Reconciliation Process:
Automatic Reconciliation: Since each transaction has a dedicated Virtual Account, reconciliation happens instantly without manual intervention.
2. One Virtual Account per Merchant/Beneficiary
This model assigns a fixed virtual account to each merchant or beneficiary (for example, a specific seller in a marketplace). All payments directed to that merchant or beneficiary are received through this single virtual account.
Advantages: This simplifies account management if the number of merchants/beneficiaries is lower than the number of transactions. It allows you to consolidate all income from a merchant into a single point, which can be useful for internal reporting or consolidated payments to that beneficiary.
Ideal for: Marketplaces with multiple sellers (where each seller has their own virtual account), or businesses with different business units that receive payments independently.
Reconciliation Process:
Automatic Reconciliation: Payments are automatically matched to the correct beneficiary that has a dedicated account.
3. One Virtual Account per Payer
Under this scheme, a unique and permanent virtual account is assigned to each of your recurring resident payers or customers. Once created, the payer will always use the same virtual account for all their transactions with you.
Advantages: This provides a very simple payment experience for the recurring customer, as they always use the same details. It facilitates tracking of a specific customer's payment history and is excellent for identifying subscriptions or recurring payments.
Ideal for: Wallets, subscription services, membership platforms, utility services, or any business with a recurring customer base that makes periodic payments.
Reconciliation Process:
Auto-Matched via Sender Name: Ensures only authorized payments are processed.
Requires KYC/Name Verification: Prevents mismatched payments.
4. Omnibus Virtual Account (XT - Aggregate Model)
In the Omnibus Virtual Account (or "Pooled Account") model, a single virtual account is used to receive payments from multiple payers or for various transactions. Reconciliation isn't based on the virtual account itself, but on additional information included in the transfer's reference. Localpayment provides useful reconciliation data in the webhook, when available, including detailed pay-in information like sender details, reference IDs, and timestamps to help you identify each payment.
Advantages: This reduces the complexity of managing a large number of individual virtual accounts. It's useful when creating an account per payer/transaction isn't feasible or necessary.
Considerations: This model requires the payer to include a specific payment reference (e.g., an invoice number, customer ID) in the bank transfer description. Reconciliation depends on your system's ability to read and process these references. If the reference is incorrect or missing, reconciliation may become manual.
Ideal for: Businesses handling mass payments from different sources that require a specific reference to identify each transaction, or when local regulations don't permit assigning individual virtual accounts to each payer.
Reconciliation Process:
Manual Effort Required: Payments must be matched using:
Sender’s bank details (name, account number).
Payment references (invoice ID, notes).
Transaction timestamps.
Model Comparison Table
Per Transaction
No
High
Transaction-level
Optional
Easy
Per Merchant
Yes
Medium
Merchant-level
Optional
Medium
Per Payer
Yes
High
Customer-level
Required
Easy
Omnibus
Yes
Manual
Global
Optional
High
Fields that can be use for reconciliation
The following fields are found in the payin response and can be used to reconcile the payments:
The
payerandbankobjects can be used to get details like:Document type
Name and Last name
Account number
Bank
Example Payin Response
"payer": {
"type": "INDIVIDUAL",
"name": "John",
"lastName": "Bravo Lopez",
"document": {
"type": "RUT",
"id": "166165xxx"
},
"bank": {
"name": "Banco de crédito e inversiones (BCI)",
"code": "016",
"branch": {},
"account": {
"type": "C",
"number": "57229333"
}
To assist you in tracing the transaction, the payer can provide a user reference in the
trackingobject. This reference can also be consulted in the User Reference field of the Panel report and the webhook.
Example Payin Response
"tracking": {
"id": "Z4K6DVNOD41X07EG95J8LQ",
"reference": "Z4K6DVNOD41X07EG95J8LQ",
"concept": "hook CVU api transaction"
}Last updated
Was this helpful?