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.
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.
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.
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 payin 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: 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.
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
Medium
Global
Optional
High
How to Reconcile Your Virtual Account Payments
Effectively reconciling virtual account transactions is critical for ensuring accurate financial records and delivering seamless experiences to your customers. Localpayment provides detailed webhook notifications and downloadable reports to help merchants identify incoming payments and match them to the corresponding customer or transaction.
Understanding the Payin Webhook for Reconciliation
The webhook notification is the primary mechanism for real-time reconciliation. When a bank transfer is received through a virtual account, Localpayment automatically sends a webhook containing all relevant payment details. This includes key identifiers and metadata necessary to accurately match the transaction with your internal records.
Here's an example of a typical payin webhook payload:
{
"transactionType": "PayIn",
"externalId": "7c35cd9a-9236-49d5-843e-050ccfc18491",
"internalId": "e167a206-d92c-4cbc-b12d-438c00c3be5c",
"paymentMethod": {
"type": "BankTransfer",
"code": "1630",
"flow": "DIRECT"
},
"country": "MEX",
"currency": "MXN",
"amount": 10000,
"accountNumber": "484.484.00000011",
"confirmed": {
"currency": "MXN",
"fxQuote": 1,
"amount": 10000
},
"payment": {
"currency": "MXN",
"fxQuote": 1,
"financingFee": 0,
"amount": 10000
},
"localTaxes": [],
"withHoldings": [],
"fees": {
"description": "Fee",
"currency": "MXN",
"fxSource": 19.21269714,
"fxQuote": 19.21269714,
"amount": 3.84,
"account": "484.484.00000011"
},
"status": {
"code": "200",
"description": "COMPLETED",
"detail": "The payin was credited"
},
"beneficiary": {
"type": "INDIVIDUAL",
"name": "John",
"lastName": "Doe",
"document": {
"type": "CC",
"id": "53112345"
},
"bank": {
"account": {
"number": "646011319800153783"
}
},
"informedName": "John Doe"
},
"merchant": {
"type": "COMPANY",
"name": "My company"
},
"payer": {
"type": "aINDIVIDUAL",
"name": "Alicia",
"lastName": "Doe",
"document": {
"type": "CC",
"id": "53100006"
},
"email": "[email protected]",
"bank": {
"name": "HSBC México",
"code": "021",
"branch": {},
"account": {
"type": "C",
"number": "646011319800153851"
}
}
},
"date": {
"creationDate": "2025-06-23T13:15:04.133",
"processedDate": "2025-06-23T13:15:04.385"
},
"errors": [],
"referenceCode": "DXRE-CBUI-ZNR1",
"tracking": {
"id": "HSBC101234",
"reference": "1",
"concept": "1"
}
}The following fields included in the webhook can be used to identify and match payments:
externalId
Unique ID generated by the merchant when creating the virtual account.
accountNumber
Merchant account number.
amount
Amount received.
currency
Transaction currency (e.g., MXN , BRL, CLP).
payer.name / payer.lastName
Full name of the payer.
payer.document.id
Payer’s national ID (if available).
payer.bank.account.number
Originating account number used by the customer.
beneficiary.name / beneficiary.document.id
Name and ID of the virtual account holder.
tracking.id, tracking.reference, tracking.concept
Additional metadata to assist reconciliation.
To help you trace and identify transactions, the payer can include a payment reference when initiating the bank transfer (if supported by the sending bank). This reference is automatically mapped to the tracking object in the webhook response.
Note: Currently, the
trackingobject is exclusively available within webhooks and is not included in downloadable "Transaction Details" reports or API queries.
Example Payin Response
"tracking": {
"id": "Z4K6DVNOD41X07EG95J8LA",
"reference": "Z4K6DVMOD41X07EG95J8LQ",
"concept": "hook CVU api transaction"
}Accessing Historical Transaction Data
In addition to real-time webhooks, Localpayment provides tools for accessing past transaction data, which is useful for audits, generating reports, or re-processing any missed webhook notifications:
API Queries: You can programmatically query the Localpayment API to retrieve details of past transactions. This allows you to fetch specific transactions or a range of transactions based on various criteria (e.g., date, status). For more information, refer to the Check Payment list endpoint.
Panel Reports: Your Localpayment Panel allows you to download comprehensive "Transaction Details" reports. These reports include a wide array of data points (e.g., Country, Creation Date, External ID, Payer Name, Amount, Status, etc.) which can be exported and used for offline reconciliation and auditing. For more information, please refer to the Reports section of the documentation.
Additional Notes
Webhook notifications are typically sent in real time, though slight delays may occasionally occur depending on bank processing.
For omnibus virtual accounts, successful reconciliation depends on accurately identifying the payer. This can be achieved by leveraging key fields from the webhook—such as
payer.bank.account.number,payer.name, orpayer.document.id—and by mapping thetrackingobject to your internal transaction records. Proper reference management is essential to ensure accurate matching.In countries like Chile, high-value transactions (≥ 7,000,000 CLP) may not include detailed payer data, and merchants are responsible for requesting missing information from the payer if needed.
By implementing these strategies, you can ensure accurate and efficient reconciliation of all payments received through your Localpayment virtual accounts.
Last updated
Was this helpful?