QR Payments in Argentine Restaurants — How the Market Actually Works

Argentina has one of the most sophisticated QR payment ecosystems in Latin America — and one of the most misunderstood from the outside. Mercado Pago, Modo, Cuenta DNI, and instant bank transfers all coexist in the same casual dining checkout moment, often within the same table split. More than 60% of restaurant bills in Buenos Aires's casual and mid-market dining segments are now settled through a digital wallet or instant transfer, not cash.

For international operators or investors looking at the Argentine market, that stat matters. But the mechanics behind it — how the payment rails work, what the regulatory environment looks like, and what a restaurant needs to technically integrate — are almost never explained well. This guide covers all of it.

The payment rails: Mercado Pago, Modo, Cuenta DNI, and transfers

Argentina's QR payment landscape is fragmented by design. There is no single dominant rail. Understanding each one is essential before designing a payment flow.

Mercado Pago is the largest and most universal. Founded by MercadoLibre (Latin America's Amazon equivalent), Mercado Pago operates both as a digital wallet and as a payment processor. It accepts balance from the Mercado Pago account itself, plus debit and credit cards linked to the account. QR codes through Mercado Pago can be static (a fixed destination account) or dynamic (generated per-transaction with a preset amount). Settlement speed depends on the plan: wallet-to-wallet payments settle instantly; card-funded payments typically settle within 24–48 hours. Merchant fees in 2026 range from roughly 0.8% to 2.99% per transaction depending on monthly volume and account type. Virtually every adult Argentine with a smartphone has some version of Mercado Pago active.

Modo is a federated banking QR standard backed by Argentina's major traditional banks — Santander, Galicia, BBVA, Macro, Banco Ciudad, and others. Customers use it from within their own bank's app or through the standalone Modo app. Payments settle instantly into the merchant's bank account. Merchant fees are comparable to or slightly lower than Mercado Pago for the banked segment. Operationally, Modo tends to correlate with higher-ticket purchases: the customer base skews toward formally employed, bank-account-holding adults who are comfortable with higher per-meal spend.

Cuenta DNI is a digital wallet run by Banco Provincia (Buenos Aires Province's public bank). It has specific and high penetration in Greater Buenos Aires (the GBA conurbano — the dense suburban belt around the capital) and should not be dismissed as a niche product. In suburban Buenos Aires restaurants, there is a meaningful share of customers whose only active digital wallet is Cuenta DNI. Ignoring it means excluding a real segment of the local population.

Instant bank transfer (CBU/CVU) is the infrastructure-level transfer system. CBU is a Uniform Bank Key — a 22-digit code that identifies a traditional bank account. CVU is its virtual wallet equivalent (Mercado Pago and other digital wallets have CVUs). Customers can transfer directly from any bank app or wallet to a restaurant's CBU or CVU alias without needing a QR code at all. This method is common and trusted, but it creates reconciliation complexity: the transfer arrives in the restaurant's bank account without any reference to the specific table or bill. Someone has to match it manually.

Physical card (posnet) still matters, particularly for high-ticket meals and for customers paying in installments. Argentina's "cuotas sin interés" (interest-free installments) programs — offered by banks and by Mercado Pago — are a real purchasing lever for dinners above a certain price point. Customers paying for a $80,000 ARS tasting menu in twelve installments is a genuine use case, not an edge case.

Cryptocurrency and USD cash is a growing niche in high-tourist-traffic areas: San Telmo, Palermo, the Buenos Aires waterfront, and resort cities like Mar del Plata in summer. With Argentina's historically volatile peso, some tourist-facing restaurants explicitly accept USD cash or USDT stablecoin as a service differentiator. This is a niche, not a mainstream requirement — but in the right context, it meaningfully extends reach to international visitors.

Static QR vs. dynamic QR: the distinction that defines the operation

The most consequential technical decision a restaurant makes about QR payments in Argentina is whether to use static or dynamic QR codes. Most operators start with static because it's free and instant. Most regret it within a month.

Static QR is a printed code that always points to the same account. The customer scans it, sees the merchant name, types in the amount, and pays. The merchant receives a notification: "X pesos received from account Y."

The problem with static QR in a sit-down restaurant is structural. First, there is no link to any specific table or open bill: the system sees an incoming payment but has no idea which table it corresponds to, which order it covers, or which shift it belongs to. Manual reconciliation — matching timestamps to table logs, amounts to bills — is the only way to close the books. Second, it does not support bill splitting: four people paying the same static QR in different amounts generates four disconnected transactions with no shared reference. Third, there are no order-level metadata attached: the payment record carries a timestamp and an amount, nothing else.

Dynamic QR is generated at the moment of payment by the restaurant's management system, linked to a specific open table bill and a specific amount. The customer scans, sees the merchant name and amount pre-filled, confirms, and pays. The restaurant's system receives the confirmation with full metadata: table, bill, amount, payment rail, timestamp. The bill closes or advances automatically.

This distinction also matters for AFIP compliance (explained in the next section): dynamic QR generates structured, auditable payment records that can feed directly into accounting workflows. Static QR generates raw transaction notifications that require human interpretation before they become useful records.

AFIP, monotributo, and the fiscal reality of digital payments

AFIP is Argentina's federal tax authority — roughly equivalent to the IRS in the United States or HMRC in the UK. Every business operating in Argentina interacts with AFIP for income reporting, VAT, and payroll compliance.

Argentine restaurants typically operate under one of two tax regimes. Monotributo (simplified regime) is a flat monthly contribution covering income tax, VAT, and social security. It is categorized by annual revenue: there are multiple categories (A through K as of 2026) with increasing revenue ceilings and contribution amounts. When a business exceeds the ceiling of its current category, it must recategorize upward — with higher monthly obligations. Responsable Inscripto (registered VAT payer) is the full regime, applicable to businesses that exceed monotributo limits or choose to register for VAT. Under this regime, the restaurant charges and remits VAT (currently 21% in Argentina), claims VAT credits on inputs, and files monthly declarations.

QR payments create income traceability that did not exist in the cash economy. For a business operating under monotributo, QR payments arriving through Mercado Pago or Modo generate auditable transaction records in the merchant's account — records that AFIP can, in principle, access. This does not create a new tax problem. The revenue existed regardless of payment method. What changes is visibility: AFIP can now see it without requesting manual records.

The practical implication for monotributo operators: if QR-traceable income from digital payments approaches the annual revenue ceiling of your current category, you need to recategorize proactively. Waiting for AFIP to identify the discrepancy results in retroactive adjustments, penalties, and interest. A good accountant (contador) will monitor this quarterly using the platform's payment reports.

For responsable inscripto restaurants, the QR integration simplifies VAT reconciliation: each payment record carries rail-level metadata that maps directly to the libro de IVA ventas (VAT sales ledger) without requiring manual entry.

The advice that applies regardless of regime: before activating any QR system, consult with your contador about how the payment flow is structured. Specifically: does revenue land in the restaurant's own bank account? Does it route through Mercado Pago and settle after a fee deduction? Are there IIBB (Ingresos Brutos, the provincial gross revenue tax) withholding implications from the payment processor? The tax treatment follows the technical flow, and different configurations generate different obligations.

How to build the right payment flow for a table-service restaurant

A well-integrated QR payment flow for an Argentine restaurant with table service looks like this:

The customer scans the table QR code from their phone. No app download required — a mobile web session opens, linked to the table and the venue. They see the current open bill, or the menu if they want to add items.

If the group wants to split the bill, they select a splitting mode: equal shares, by individual item, or custom amounts. Each person sees their portion on their own screen.

Each person selects their preferred payment rail: Mercado Pago, Modo, Cuenta DNI, bank transfer, card. The system presents the rails the venue has configured as active.

Each person pays. The bill updates in real time. The server doesn't need to do anything — they see the status on the management system.

When everyone has paid their portion, the table closes automatically. The system records the full transaction: total, per-rail breakdown, tip if added, and the order items the payment covers.

The critical architectural requirement: the payment layer and the order management layer must be the same system, not two separate tools synced through a webhook. When they're the same system, bill closure is automatic and reconciliation is immediate. When they're separate, every payment generates a manual reconciliation task.

QR table payments on Payverge implements this flow end-to-end — dynamic QR per table, multi-rail support within a single session, automatic table closure, and full payment records for accounting export.

Alternative payment handling: cash, direct transfers, and exceptions

QR payments will not cover every table. Older customers who do not use digital wallets, corporate accounts paying by invoice, and situations where the customer's app simply fails to connect all require a fallback.

The right pattern is a structured alternative payment record — not a verbal "they paid, close it." The server registers the method and the amount ("$14,200 in cash" or "transfer confirmed, reference 2034-XXX"), and the system holds the table in a pending state until the payment is confirmed. This prevents two recurring operational failures:

The customer says they transferred but the transfer hasn't cleared. The system keeps the bill in "pending" status until the deposit appears in the account. The server doesn't have to make a judgment call about whether to let the customer leave.

Cash that goes into the register but nobody closes the table. The system requires a payment record before releasing the table. The day's cash report reflects reality.

Alternative payment handling is not a workaround for a QR system — it is part of a complete payment architecture. Any system that does not support it has a structural blind spot.

Tips in the QR flow

Argentina's tipping culture in restaurant contexts is meaningful but informal — a 10% tip is standard in Buenos Aires casual dining, though it is not mandatory and cash tips have historically been the norm. The shift to digital payments creates an opportunity to recover the tipping behavior that the cash-to-digital transition was quietly eroding.

The right tip flow has three components:

Pre-payment prompt with preset options. The system presents 0% / 10% / 15% / custom before the payment confirmation. No more than three presets plus a manual entry field. Additional friction — a separate screen, a pop-up after payment — drops tip rates materially.

Proportional application across splits. When a bill is split and each person pays their share, the tip applies proportionally to each individual payment. It does not fall into an unallocated bucket or require manual distribution.

Per-shift, per-server reporting. The system records which tips were generated on which bills and in which shifts. Pool distribution can be automated according to the venue's configured rules — equal shares, by role weight, or mixed. Servers can see their accumulated tips per shift without depending on a manager's report.

When the prompt is well-designed and the flow is low-friction, tip averages rise. This is not a speculation — it reflects the behavioral reality that when given a clean "10%" button, many customers who would have skipped a cash tip take it. That is direct income for the floor team without any change to the restaurant's own margin.

For a complete guide to digital tip distribution, staff banking, and AFIP implications for tip income in Argentina, the digital tipping guide for Argentine restaurants (available in Spanish) covers the full operational and fiscal picture.

Reconciliation: what "QR integrated" actually means for your books

There is a meaningful difference between a system that accepts QR payments and a system where QR payments are integrated. The difference is whether the payment record carries enough metadata to feed directly into accounting without human interpretation.

An integrated QR payment record contains:

• The table and bill it belongs to.
• The payment rail used (Mercado Pago, Modo, card, cash).
• The exact amount and timestamp.
• The order items the payment covers.
• Any tip amount, separately attributed.

That data structure makes three things automatic that would otherwise be manual: the day's revenue total by payment rail, the bank account reconciliation (each MP settlement matches a set of transaction records in the system), and the per-rail breakdown required for AFIP income reporting.

For a restaurant running on manual reconciliation — matching Mercado Pago notifications to paper tickets on Monday mornings — the move to integrated QR is not a convenience upgrade. It is a structural reduction in back-office labor and a meaningful improvement in the accuracy of the tax filing.

The discount-for-QR mistake

A common operator instinct is to offer 5% off for QR payment to accelerate adoption. The logic seems sound: you're incentivizing the method with better reconciliation characteristics. The problem is that this effectively penalizes the customers who pay by card — who, in most Argentine casual dining contexts, have a meaningfully higher average spend than the average. Customers putting a high-end dinner on a bank card and paying in installments tend to order more.

A rail-specific discount depresses total average order value by pushing the check composition toward the lower-spending QR-paying segment while making the higher-spending card segment feel implicitly taxed.

The alternative that works: price parity across all rails, combined with a service benefit tied to check size — a complimentary dessert on bills above a certain amount, coffee included for tables of two or more, a tasting bundle available at a threshold. This lifts AOV without penalizing any payment method and without creating pricing complexity that confuses guests.

What to prioritize

For an Argentine restaurant operator building or upgrading its payment layer, the priority order is:

First: Dynamic QR linked to the open table bill — not static QR. This is the foundation. Everything else depends on it.

Second: Multi-rail support within a single bill — Mercado Pago, Modo, Cuenta DNI, and card from the same session. A guest table where one person uses Mercado Pago and another uses Modo should not require two separate payment flows.

Third: Structured alternative payment handling for cash, direct transfers, and exceptions. Cover the 100% of cases, not just the 60% who pay by QR.

Fourth: Tip prompting before payment with proportional split support and per-shift reporting.

Fifth: Accounting export with per-rail metadata for AFIP compliance and bank reconciliation.

For the broader context on reducing operating costs in Argentine restaurants using digital infrastructure and AI tooling, see our guide to cost reduction for Argentine restaurants (in Spanish), which covers the five highest-impact levers on the P&L.

See how QR table ordering works