Contactless Pix: How Redirectless Payments Work in Open Finance Brasil

This post is a follow-up to the How Open Finance Brasil is Transforming Payments with Contactless Pix article which introduced Contactless Pix, a transformative user experience for Open Finance payments in Brazil. While that post explored the user-facing benefits, this one dives into the technical architecture and design decisions that made it possible.

Our objective is to provide a closer look at the standards-based mechanisms used to reduce friction in Open Finance payments.

This article draws on Raidiam’s experience helping to design and implement the standards and infrastructure underpinning Brazil’s Open Finance ecosystem, as well as our work shaping international specifications through bodies like the OpenID Foundation.

Reducing Friction: The UX Challenge in Open Finance

One of the core challenges in Open Finance adoption has been the friction introduced by redirection.
This process requires users to be redirected to their bank every time they want to authorize a payment, adding latency and disrupting the user experience—especially when compared to the smooth, one-click behavior of card payments or digital wallets.

The goal of Contactless Pix is to remove this friction, while maintaining the security and accountability guaranteed by Open Finance standards.

How Open Finance Payments Work Today: OAuth and Redirection

In the previous model defined by the Open Finance Brasil Payment APIs, initiating a payment follows these steps:

1. The user is redirected to their bank — the Account Servicing Payment Service Provider (ASPSP).

2. They authenticate and authorize the payment.

3. The bank issues an authorization code.

4. The Third Party Provider (TPP) exchanges the code for an access token and uses it to call the payments API.

This redirection process must occur for each payment initiation, even if the TPP already has a refresh token from a previous session.

Contactless Pix and Redirectless Payments: Authorize Once, Use Many

To simplify this flow, the Enrollments API introduces the concept of redirectless payments:

1. The user is redirected once to enroll their device, where a device key is bound to the payment.

2. They define usage limits and expiration rules.

3. The bank issues a refresh token code.

4. The TPP stores a refresh token, while the device’s private key is stored securely on the device.

5. Future payments can be authorized without redirection, as long as they stay within predefined constraints.

This allows users to enjoy a card-like experience — fast, seamless, and secure — while still complying with Open Finance security models.

How Asymmetric Encryption and FIDO2 Power Contactless Pix

At the heart of this new model is asymmetric encryption.
Asymmetric encryption uses a key pair:

• Public key — shared with others.

• Private key — securely stored on the user’s device.

Only the private key can sign messages, and only the public key can verify those signatures.
This allows a bank to verify that a request was made by a device holding the expected private key — without ever seeing the private key itself.

To implement this cryptographic flow, Open Finance Brasil adopted the FIDO2/WebAuthn standard, supported by most smartphones and browsers. It enables the TPP to request the generation of cryptographic keys on the user’s device, which can later be used after the user re-authenticates using biometrics, PINs, or other device-level security.

FIDO2 is not used here for passwordless login, but rather as a framework for asymmetric key management.

Enrollments API in Open Finance Brasil: Step-by-Step Guide

Here’s how the redirectless payment model works in practice:

1. Create the Enrollment

• The TPP calls POST /enrollments to start the device binding process.
  The enrollment starts in the AWAITING_RISK_SIGNALS state.

• The TPP must send risk data via POST /enrollments/{id}/risk-signals, including device details, IP address, and platform.

2. Redirect for Consent and Limits

Once the risk data is received, the enrollment moves to AWAITING_ACCOUNT_HOLDER_VALIDATION.
The user is redirected to the ASPSP and:

• Authenticates with their bank.

• Confirms account ownership.

• Defines limits (daily and per-transaction).

• Optionally names the device.

This is the only redirection needed.
Upon successful consent, the bank issues a refresh token to the TPP.

3. FIDO Registration

The enrollment moves to AWAITING_ENROLLMENT, waiting for the device key registration.
The TPP then:

1. Calls GET /enrollments/{id}/fido-registration-options to get a challenge.

2. Uses the user's device to generate a key pair and sign the challenge.

3. Calls POST /enrollments/{id}/fido-registration to send the signed challenge and public key.

If successful, the enrollment moves to the AUTHORISED state.
The bank now knows the device’s public key and has proof that the user possesses the matching private key.

At this point, the device is trusted for future payment authorizations without requiring redirection.

How to Execute Payments with Contactless Pix Enrollments

Once enrollment is complete, the TPP can initiate payments using the Payments API.

1. Create a Consent

Use the standard POST /consents endpoint to define payment details and scope.

2. Authorize the Consent without Redirection

• Call GET /enrollments/{id}/fido-sign-options to get a challenge.

• Sign it on the user’s device using the private key.

• Send the signed challenge and risk data to POST /consents/{id}/authorise.

3. Bank Decision

The ASPSP verifies the signature and all risk signals.
It may approve or reject the authorization based on internal fraud checks and policies.

4. Execute the Payment

If authorized, the TPP can call POST /payments using either the access token previously issued via the Enrollments flow.

An example video showing a payment authorized through a pre-set enrollment is available at this link. (TBD)

A Deep Dive on Security and Liability in Brazil’s Open Finance Ecosystem

Redirectless payments introduce a substantial shift in Open Finance’s security architecture.
Traditionally, ecosystems like Open Finance Brazil adopt client-bound tokens — tokens and refresh tokens usable only by the specific TPP that originally received them.
This ensures that possession of a token alone is insufficient; the client application must also be verified.

The Contactless Pix model goes further. By introducing device-bound FIDO credentials, the ecosystem moves toward a user-bound token architecture — where the refresh token is only useful if the user is physically present and holding the enrolled device.

Before authorizing a payment, the credential must sign a cryptographic challenge issued by the bank — binding the process to the user’s real-world behavior and hardware.

This model still complies with FAPI: the signed challenge is treated as a risk signal, not a protocol requirement. OAuth2 grant types and token lifecycles remain unchanged.

From Static Trust to Dynamic Risk Evaluation

However, this shift moves liability and decision-making back to the ASPSP, who must determine whether the proof of device possession is sufficient to approve a payment.

Since users are no longer redirected to the bank for each authorization, the ASPSP must decide, based on telemetry and cryptographic signatures, whether:

• The user is indeed present.

• The signature came from a secure, attested device.

• The request originated from a legitimate application.

This transforms trust from a static, redirect-based validation into a dynamic, contextual process evaluated in real time.
ASPSPs assume greater discretion and responsibility, deciding whether the available evidence suffices to authorize a payment under existing liability rules.

Open Finance Brasil’s Trust Framework and Origin Validation

A critical enabler of this model is the Trust Framework, implemented through Raidiam Connect.
During Dynamic Client Registration (DCR), each TPP declares a list of valid software_origin_uris — allowed origins (e.g., app package IDs or URLs) from which FIDO credentials may be created and used.

Raidiam contributed to designing this approach within Brazil’s Open Finance working groups and implemented the Trust Framework and conformance tools that underpin secure, compliant deployments.
We also bring insights from this work into global standards bodies such as the OpenID Foundation, helping shape profiles like FAPI 2.0 Baseline and Advanced Security Profiles.

During both enrollment and payment flows, the ASPSP must validate that the FIDO origin matches one of the registered software_origin_uris.
This prevents credential spoofing, such as credentials generated by malicious third-party apps or browsers.
The combination of origin enforcement and attested device validation makes it possible to securely delegate credential creation to the TPP while maintaining strong authenticity guarantees.

Credential Delegation in Redirectless Open Finance Payments

In traditional redirect-based flows, the bank creates and owns the authentication context.
In the redirectless model, credential creation is fully delegated to the TPP, without direct ASPSP–user interaction during FIDO registration.

This delegation brings scalability and UX benefits but also design trade-offs.
The ASPSP must trust that the public key received during enrollment was generated by the real user on a secure device using an approved application.
It cannot verify this directly, so it relies on:

• FIDO device attestation — confirming the credential originates from a supported authenticator.

• Origin validation — enforced via software_origin_uris declared during DCR and verified at runtime.

• Risk signal evaluation — assessing challenge signatures, device info, and behavioral patterns.

Fraud prevention thus becomes probabilistic and contextual, not deterministic.
The redirectless model enables richer telemetry and dynamic decision-making but requires a strong risk framework and liability governance.

It’s a strategic shift — enabling smoother journeys, interoperability, and extensibility — but only when backed by a robust Trust Framework and clear rules.

The Future of Open Finance Payments

Contactless Pix shows how open ecosystems can adopt a layered security model: preserving user consent and bank-level validation while removing friction from the payment journey.

It’s a blueprint not only for Brazil but for other jurisdictions seeking to combine user experience with trust and compliance.

To learn more about how Raidiam can support your Open Finance initiatives, get in touch with our team.