Reconciliation Models

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.

Models

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 Submerchant

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 User/Payer

Under this scheme, a unique and permanent virtual account is assigned to each of your recurring resident clients or customers. Once created, the client 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. These models are configured directly at the account level and cannot be selected or changed via API or other self-service means. To discuss which reconciliation model is best suited for your operations and to configure it for your account, please reach out to your Localpayment.

Model Comparison

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.

Payin Webhook

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": "TRANSFERENCIA-568GYKNXWJELWYGP2MPRZ5",
  "internalId": "5aced5da-40c1-4bec-85ff-c8cd1bcb4526",
  "paymentMethod": {
    "type": "BankTransfer",
    "code": "1025",
    "flow": "DIRECT"
  },
  "country": "ARG",
  "currency": "ARS",
  "amount": 1.09,
  "accountNumber": "{{YourAccountNumber}}",
  "confirmed": {
    "currency": "ARS",
    "fxQuote": 1,
    "amount": 1.09
  },
  "payment": {
    "currency": "ARS",
    "fxQuote": 1,
    "financingFee": 0,
    "amount": 1.09
  },
  "localTaxes": [
    {
      "code": "0001",
      "percentage": 1.2,
      "description": "IDC",
      "currency": "ARS",
      "fxSource": 1193.82,
      "fxQuote": 0,
      "amount": 0.01,
      "account": "{{YourAccountNumber}}"
    }
  ],
  "withHoldings": [],
  "fees": {
    "description": "Fee",
    "currency": "ARS",
    "fxSource": 1170.50002,
    "fxQuote": 1,
    "amount": 0,
    "account": "{{YourAccountNumber}}"
  },
  "status": {
    "code": "200",
    "description": "COMPLETED",
    "detail": "The payin was credited"
  },
  "beneficiary": {
    "type": "INDIVIDUAL",
    "name": "Camilo",
    "lastName": "Sabogal",
    "fullName": "Camilo Sabogal",
    "document": {
      "type": "CUIT",
      "id": "20314567894"
    },
    "bank": {
      "account": {
        "number": "0000369600000000000161"
      }
    },
    "informedName": "Unknown"
  },
  "merchant": {
    "type": "INDIVIDUAL",
    "name": "Localpayment Test",
    "lastName": "Localpayment Test"
  },
  "payer": {
    "type": "INDIVIDUAL",
    "name": "Carlos",
    "lastName": "Mendez",
    "fullName": "Carlos Mendez",
    "document": {
      "type": "CUIT",
      "id": "20314567894"
    },
    "email": "[email protected]",
    "bank": {
      "name": "BANCO DE GALICIA Y BUENOS AIRES S.A.U.",
      "code": "007",
      "branch": {},
      "account": {
        "type": "C",
        "number": "0070055930004044938502"
      }
    }
  },
  "date": {
    "creationDate": "2025-04-30T17:26:37.186",
    "processedDate": "2025-04-30T17:26:37.363"
  },
  "errors": [],
  "referenceCode": "DHF2-XOHO-NE77",
  "tracking": {
    "id": "7L8GYKNXWJELWYGP2MPRZ5",
    "reference": "7L8GYKNXWJELWYGP2MPRZ5",
    "concept": "CVU TEST"
  }
}

The following fields included in the webhook can be used to identify and match payments:

To facilitate transaction identification, the payer can add a payment reference when making the transfer (subject to their bank’s support). The reference will appear automatically within the tracking object of the webhook response.

⚠️

Important

• The tracking object is currently supported in webhooks only. It is not accessible in "Transaction Details" reports or through the API.
• For Mexico, the externalId corresponds to Banco de México's tracking key (Clave de Rastreo), making it the authoritative field for reconciliation.

Example Payin Tracking Response

 "tracking": {
    "id": "7L8GYKNXWJELWYGP2MPRZ5",
    "reference": "7L8GYKNXWJELWYGP2MPRZ5",
    "concept": "CVU TEST"
  }

 "tracking": {
    "id": "E0000000022250417170028008753346",
    "reference": "",
    "concept": "11778498595"
  }

"tracking": {
    "id": "000739531483",
    "reference": "2025-07-16-12.10.09.237295",
    "concept": "Test 928630996"
  }

 "tracking": {
    "id": "lpv3_1111-19feb2024-2400",
    "reference": "999999",
    "concept": "concepto pago LPV3_4707"
  }

 "tracking": {
      "id": "2025102011074908084191797675",
      "reference": "00100000297079044806",
      "concept": ""
    }

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, or payer.document.id—and by mapping the tracking object to your internal transaction records. Proper reference management is essential to ensure accurate matching.

By implementing these strategies, you can ensure accurate and efficient reconciliation of all payments received through your Localpayment virtual accounts.