Introduction of changes to Voucher (PAT) Program Integration - Visa, Mastercard, and Elo

Context

New employee benefit payment rails are being developed by Visa, Mastercard, and Elo, driven primarily by evolving regulations in Brazil. The new legal framework aims to shift the market from traditional closed-loop systems to more competitive and transparent open-loop solutions. However it's unclear how much percentage of the closed-loop volume will eventually migrate to the open-loop. The primary goal of this change is to increase competition, provide more freedom of choice for both merchants and employees, and ultimately reduce costs for merchants.

Vouchers that currently operate on the open-loop from schemes Visa, Mastercard and ELO through Credit and/or Debit rails (such as Cash, Flash, iFood benefícios, Mercado Pago benefícios, etc) will migrate their BINs to process the transactions through the new voucher rails.

Vouchers that currently operate on the closed-loop from schemes VR, Ticket, Pluxee and Alelo will not be impacted. The processing will remain the same as today. The only potential impact is for cards that they decide to issue with an open-loop scheme (Visa, Mastercard, ELO), which we don't have visibility of potential volume nor dates that this will happen. 

Key motivators and outcomes of this transition include:

• Regulatory Compliance: Adherence to new laws (like Law 14.442/2022) and Central Bank resolutions that promote open-loop arrangements for benefits such as PAT (Worker's Food Program).

• Enhanced User Experience: Open-loop systems allow benefit cards to be used at a much wider network of merchants. They also enable modern payment methods like contactless, QR codes, and digital wallets.

• Increased Competition and Innovation: The regulations are designed to foster a more competitive market, encouraging new issuers and solutions, such as combining multiple benefit types on a single card.

• New Business Opportunities: The shift creates opportunities for issuers to expand their portfolios and for acquirers to capture a significant new volume of transactions.

Overview and Timeline

Since February 2026, Adyen has supported PAT (Worker’s Food Program) vouchers in Brazil via the market’s new processing rails. To ensure compliance, merchants must transition their systems to these new rails for all PAT benefit transactions. While the industry mandated the go-live for November 3rd, 2025, all PAT-based voucher captures must be processed exclusively through this new infrastructure effective February 2026.

Technical Integration and Development

Regarding technical documentation, the API request for authorization will require the following parameters:

• FoundingSource: Prepaid

• TXvariant will be: visa_voucher_br, elo_voucher_br, mc_voucher_br

Please note that the endpoints remain unchanged, and processing does not differ between card types.

Checkout

To ensure the meal voucher tx variants are returned in the /paymentMethods response and/or presented in the Drop-in/Components UI, merchants have to set the parameter splitCardFundingSources to true in their /paymentMethods or /sessions request and enable the new meal voucher tx variants in the Customer Area. 

The /payments request will require the following parameters:

• paymentMethod.fundingSource: prepaid

• paymentMethod.brand: visa_voucher_br, elo_voucher_br, mc_voucher_br

Example of paymentMethod object in /payments request:

"paymentMethod":{

   "type":"scheme",

   "brand":"elo_voucher_br", // or mc_voucher_br/visa_voucher_br

   "encryptedCardNumber":"test_4111111111111111",

   "encryptedExpiryMonth":"test_03",

   "encryptedExpiryYear":"test_2030",

   "encryptedSecurityCode":"test_737",

   "fundingSource": "prepaid" 

}

Bin lists will be updated in the Adyen BIN table to ensure correct rail processing once transactions include the aforementioned parameters. Even though the parameters of foundingSource and TxVariant are obligatory. 

For our Classic API integration,

•  "fundingSource": "prepaid",

•  "selectedBrand": "elo_voucher_br"

"selectedBrand": "elo_voucher_br",

"fundingSource": "prepaid",

In-Person Payments

There are two ways to accept Meal Vouchers on our IPP solution.

Option A: Automatic (Adyen UI Selection)

Best for: Merchants using the Adyen UI to select Credit/Debit/Voucher (Standalone or Integrated).

• How it works: The Adyen app on the terminal handles the logic. When a regular payment request is sent to the terminal, it prompts the credit, debit or voucher button. If the shopper selects the "Voucher" button on the screen, the terminal is able to process both closed and open loop meal vouchers. 

• Requirements: 

  • PCI6: Firmware v126.5 LTS or v129+

  • PCI5: Firmware v120.11 LTS.

  • Meal Voucher payment methods are enabled.

Option B: Terminal API / Nexo (Custom POS UI Selection)

Best for: Merchants with their own custom POS interface (Integrated only).

• How it works: The merchant’s POS asks the shopper for the account type and sends that choice (“MEAL_VOUCHER”) in the integration request to the Adyen app on the terminal. The terminal then skips the account type selection screen and goes straight to processing the specific card type chosen in the Merchant POS. The terminal will still show the application (e.g. “TSF-Restaurante”, “TSF-Alimentacao”, etc.) selection screen when applicable. If the terminal receives “MEAL_VOUCHER” in the payment request the terminal is able to process both closed and open loop meal vouchers. 

• Requirements: 

• PCI6: Firmware v126.5 LTS.

• PCI5: Firmware v120.11 LTS.

• Meal Voucher payment methods are enabled.

Merchant Action: Update integration to include "selectedAccountType" = "MEAL_VOUCHER" in the SaleToPOIData. See Appendix A at the end of this page for a sample request. 

Compliance, Onboarding, and Governance

I. With a formal agreement with the Acquirer/Sub-Acquirer:

• Merchants must possess a formal "Contrato de Credenciamento" (Acquirer Agreement) with an Elo-participating Acquirer or a Sub-Acquirer sponsored by an Acquirer. (Regulamento Elo - Arranjo de Pagamento de Benefícios, Art. 25).

II. PAT Merchant Registration & Compliance

• Merchant Eligibility for PAT: Merchants intending to accept PAT benefits must be specifically enabled and validated for this program. This entails:

  • Correct CNAE (National Classification of Economic Activities): The merchant's registered economic activity (CNAE) must align with the commercialization of meals or foodstuffs (e.g., restaurants, supermarkets). (Arranjo de Pagamento de Benefícios Elo - Visão Geral e Sub-credenciamento, p.20, 27, 30; Regulamento Elo, Art. 25, Art. 83; Elo Voucher_Arranjo de Pagamentos, p.16, 19)

  • Sanitary and Nutritional Standards: Merchants must adhere to all applicable sanitary and nutritional regulations. Acquirers/Sub-Acquirers are responsible for verifying relevant documentation or obtaining a Sanitary Permit issued by ANVISA from the merchant. (Arranjo de Pagamento de Benefícios Elo - Visão Geral e Sub-credenciamento, p.20, 27, 30; Regulamento Elo, Art. 25, Art. 83; Elo Voucher_Arranjo de Pagamentos, p.16, 19)

  • Regular Legal Registration (CNPJ): The merchant's CNPJ must be valid, and their cadastral situation up-to-date. (Arranjo de Pagamento de Benefícios Elo - Visão Geral e Sub-credenciamento, p.20, 27, 30; Regulamento Elo, Art. 25, Art. 83; Elo Voucher_Arranjo de Pagamentos, p.16, 19)

• Acquirer/Sub-Acquirer PAT Facilitator Registration: The Acquirer or Sub-Acquirer onboarding the merchant must themselves be registered with the Ministry of Labor as a PAT facilitator (with CNAE 82.99-7-02 - issuance of meal vouchers, transport vouchers, and similar). (Arranjo de Pagamento de Benefícios Elo - Visão Geral e Sub-credenciamento, p.21, 22, 24, 27, 28; Elo Voucher_Arranjo de Pagamentos, p.15, 21)

III. Merchant Information and Identification:

1. Accurate Merchant Category Code (MCC):

   • The Acquirer must assign the correct MCC to the merchant, accurately reflecting their primary business activity. This is crucial for determining eligibility for various benefit types (food, meal, culture, transport). (Regulamento Elo, Art. 83; Boletim Novo Arranjo de Pagamento de Benefícios Elo, p.12-13)

Financial Flow, Settlement and Reconciliation

Nuclea’s integral role in the settlement process remains unchanged, as we have successfully achieved homologation with each voucher scheme on their respective rails. This ensures seamless integration and continued operational efficiency within the existing framework. Regarding reconciliation, the necessary files will be supplied within the existing credit reconciliation file structure, adhering to the timeline T+15. This consistency minimizes disruption and maintains the predictability of financial operations. Furthermore, there are no modifications to the handling of disputes and chargebacks; these processes will continue to be managed in accordance with current established protocols. As for pricing, we will maintain our transparent and competitive IC++ model, which continues to provide clear cost structures and benefits for our partners. Please be aware that the Advancement of funds feature will not be available for voucher transactions at launch. We are working to enable this functionality and will provide an estimated timeline for its availability in a future update.

Certifications & Specific Requirements

Adyen will handle the terminal certification for our commercial products, eliminating the need for merchants to obtain it.

Appendix A

New field in SaleToPOIData:

{"selectedAccountType": "<ACCOUNT TYPE>"}

Possible values for Account Type:

• MEAL_VOUCHER

• CREDIT

• CHEQUE

Note: When debitPreferred and selectedAccountType are both included in the integration request, then the selectedAccountType will take precedence and its value will be applied.

Example request:

{ "SaleToPOIRequest": { "MessageHeader": { "ProtocolVersion": "3.0", "MessageClass": "Service", "MessageCategory": "Payment", "MessageType": "Request", "ServiceID": "0304111525", "SaleID": "mb-yuming", "POIID": "S1F2-000158202811139" }, "PaymentRequest": { "SaleData": { "SaleTransactionID": { "TransactionID": "8749", "TimeStamp": "2026-03-04T17:15:25+00:00" }, "SaleToPOIData": "eyJzZWxlY3RlZEFjY291bnRUeXBlIjogIk1FQUxfVk9VQ0hFUiJ9Cg==" }, "PaymentTransaction": { "AmountsReq": { "Currency": "BRL", "RequestedAmount": 1 } } } } }

Note: The SaleToPOIData value is base64 encoded. The decoded value is: {"selectedAccountType": "MEAL_VOUCHER"}