When a customer adds a card for a subscription, saves a payment method for future purchases, or adds a new credential to their account, there is an important question to answer before the first charge: is this card active and usable?
Making a real charge just to find out mixes two different intentions. Verifying a credential is one thing. Charging for a purchase is another.
Zero Auth is a card verification mechanism without a conventional financial charge. AZPay's documentation describes the operation as a nonmonetary preauthorization used to confirm that the card exists, is active, and can accept charges, without moving funds.
The concept also exists in card networks. Visa describes Account Verification as a zero-amount authorization used to check an account's status before a financial transaction.
But there is a fundamental distinction: successful verification does not guarantee that a future purchase will be approved. Zero Auth is a tool within the credential lifecycle, not a promise of future revenue.
What is Zero Auth?
Zero Auth is an operation used to verify a card credential without making a conventional purchase.
At AZPay, the documented flow sends a nonmonetary preauthorization through the payment chain. The response lets the merchant interpret the verification result before deciding how to continue the journey.
This is particularly useful when there is a gap between the moment the card is provided and the moment it will actually be used.
A subscription may start after a free trial. A marketplace may let a customer save a card before their first purchase. A B2B platform may register the payment method during onboarding and charge only when a particular service is used.
In these cases, simply storing the credential postpones the discovery of some problems. Zero Auth creates an intermediate state between receiving the credential and attempting a financial charge.
How does Zero Auth work at AZPay?
AZPay's technical documentation explains the operational flow behind the abstraction. The merchant sends a Zero Auth request to AZPay; the operation travels as a preauthorization through acquiring to the issuer; the issuer validates the credential and returns a response code; the response travels back through the chain to AZPay and then to the merchant.
The documentation also provides for automatic reversal of the preauthorization, without capture. In other words, the goal is not to complete a purchase, but to obtain a signal about the credential before a later financial transaction.
This detail matters because it shows the value of the abstraction. For the application, the intent can be expressed as “verify this credential.” Behind that call is a chain consisting of the platform, acquiring, network, and issuer, with each participant contributing to the final result.
AZPay's documented implementation includes a sandbox endpoint, request fields, response examples, return codes, and test paths. To implement the flow, the technical documentation should be treated as the source of truth, rather than this editorial article.
Does Zero Auth charge the customer anything?
The purpose of Zero Auth is to perform a verification without a conventional charge.
AZPay's documentation describes the mechanism as a zero-amount preauthorization and also notes that certain networks may require a nominal amount. In those cases, the documented flow provides for automatic reversal without capturing funds.
This nuance matters. We should not turn “Zero Auth” into a universal promise that every network and route behaves in exactly the same way. Actual behavior depends on the participating infrastructure and the rules applicable to the flow.
From the product perspective, the intent remains clear: separate credential verification from the purchase the customer actually intends to make.
Does Zero Auth guarantee that the next purchase will be approved?
No.
Successful verification tells you something about the credential at the time and in the context of that verification. It does not guarantee approval of a future transaction.
Between verification and a later purchase, the card may expire, be blocked, or be replaced. Available credit may change. The issuer may assess the future transaction differently. The risk context may change. Authentication may be required. Even the processing route may differ.
Therefore, the correct interpretation is not “approved Zero Auth means an approved future payment.”
The more precise interpretation is that the credential passed the verification performed at that time.
Where does Zero Auth fit into payment architecture?
Zero Auth makes more sense when viewed as part of a credential's lifecycle.
A card may enter the platform, be protected or tokenized, undergo verification, be associated with a customer, and then be used in one or several future transactions.
This sequence places Zero Auth alongside topics such as tokenization, card-on-file, and recurring payments, but the concepts are not equivalent.
Tokenization concerns the representation and secure handling of the credential. Card-on-file describes the context in which a credential is retained for later use. Recurring billing organizes charges over time. Zero Auth adds a possible verification step.
This separation helps build clearer systems because each operation answers a specific question.
Are Zero Auth and tokenization the same thing?
No.
Tokenization and Zero Auth solve different problems.
Tokenization concerns representing the credential so that the system does not need to handle the original PAN in every subsequent flow. Zero Auth concerns verifying the credential without a conventional charge.
A card can be tokenized without that automatically meaning it has undergone zero-amount verification. Similarly, verifying a credential does not remove the need to decide how it will be stored and used securely.
AZPay's documentation recommends combining the two concepts in certain flows: validate first and tokenize afterward, avoiding storing tokens for cards that did not pass the intended verification.
This is an architectural decision, not an equivalence between the operations.
Zero Auth and card-on-file
Card-on-file appears in experiences where users do not need to enter their card details again for every purchase.
Subscriptions, mobility, delivery, SaaS, marketplaces, and on-demand services are common examples.
The challenge is that storing a reference does not, by itself, tell you whether the credential is in a suitable condition for the intended flow.
Imagine a platform offering a free trial. On day one, the customer creates an account and provides a card. The charge takes place only weeks later.
Discovering a problem with the credential only during the first billing cycle turns an onboarding issue into a future billing problem.
Zero Auth does not eliminate future declines, but it allows the platform to obtain information about the credential before that point.
Zero Auth in subscriptions
Recurring payments make this separation in time even clearer.
A subscription may begin immediately or after a trial. It may be monthly or annual. The plan may change. It may use a credential for a long period.
In this scenario, the initial verification is only one part of the lifecycle.
A mature architecture separates credential registration, verification, subscription activation, charging, asynchronous events, retries, and subsequent charges.
This also improves observability. When something fails, the team can ask whether the problem occurred during registration, verification, financial authorization, authentication, routing, or communication with a participant.
The more explicitly these states are modeled, the easier it is to diagnose system behavior.
What does Zero Auth not solve?
Zero Auth does not replace financial authorization, authentication, fraud prevention, tokenization, or a recurring payments strategy.
It also does not guarantee future funds or credit availability, eliminate declines, or turn a verified credential into a permanently valid one.
This matters because payment technologies are often presented as standalone solutions to problems that belong to systems.
Approval rates do not depend on a single feature. Conversion does not depend only on checkout. Resilience does not depend only on failover. Card-on-file quality does not depend only on Zero Auth.
Payment infrastructure is a system of interdependent decisions.
What is the difference between Zero Auth and a small charge?
The main difference is the intent and type of operation.
A financial charge, however small, is still a financial operation. Account Verification and Zero Auth exist to verify the account or credential before the actual financial transaction.
Visa documents Account Verification as a zero-amount authorization. AZPay's documentation also separates verification from charging and provides for handling the specifics of networks that require a nominal amount.
This distinction improves the integration's mental model: verifying should not be treated as synonymous with purchasing.
What happens when Zero Auth is declined?
The result needs to be interpreted according to the response code and the context of the operation.
AZPay's documentation distinguishes, for example, an invalid card, expired card, transaction not permitted, restricted card, CVV mismatch, issuer unavailability, system failure, and suspected fraud.
This shows why reducing all outcomes to “it worked” or “it failed” weakens the operation.
The more useful question is: what exactly does this result mean, and what action does it allow?
Temporary unavailability is not the same as an invalid credential. A security condition should not receive the same treatment as a transient technical failure.
The documentation makes this difference concrete. An expired card calls for updating the credential. Issuer unavailability may justify another attempt. Certain system failures can receive a retry with backoff. Suspected fraud should not be treated as simple technical unavailability.
This granularity is one of Zero Auth's most useful operational aspects: the response does not just classify the credential; it can guide the system's next action.
Should Zero Auth trigger a retry?
There is no single rule for every response.
A retry makes sense when there is a technical and semantic reason to believe repeating the operation can produce a useful, safe result.
AZPay's own documentation associates different actions with the returned codes. For issuer unavailability, for example, it documents trying again later. For certain system errors, it recommends a retry with backoff. Other results call for correcting the credential or should not simply be repeated.
This principle applies to payments in general: repeating an operation just because it failed is not a resilience strategy.
Before retrying, the system needs to understand the failure type and the appropriate action.
Can Zero Auth improve conversion?
Zero Auth can help an operation be better prepared by identifying certain problems before a future charge. This does not mean implementing it on its own guarantees an increase in conversion or approval.
Conversion depends on many factors: checkout experience, authentication, risk, issuer, acquiring, credential, latency, availability, and transaction context, among others.
The responsible way to evaluate impact is to measure the actual flow.
How many credentials undergo verification? Which responses appear? How many verified credentials reach their first charge? How do those charges behave afterward? Where do technical failures arise?
Without that context, attributing a percentage gain to Zero Auth would be a promise without evidence.
Does Zero Auth replace 3DS?
No.
3DS and Zero Auth have different purposes.
3DS concerns authentication in card transactions and has its own flows. Zero Auth concerns verifying the credential without a conventional charge.
An architecture may use different mechanisms at different moments in the journey. Mixing them up creates a misunderstanding of the payment stack.
How should Zero Auth be approached in a multi-PSP architecture?
When infrastructure works with multiple providers, the question expands from “where should this be sent?” to “which route supports this operation, and with what behavior?”
Capabilities may vary between acquirers, processors, networks, and integrations. An orchestration layer needs to understand those capabilities without pretending every path is identical.
This principle extends beyond Zero Auth.
A payment route has capabilities, constraints, responses, and operational characteristics. A good abstraction offers consistency to the merchant without hiding information needed for diagnosis and decisions.
This is where orchestration stops meaning simply having more than one PSP.
Why does this matter to developers?
Because a payment API should let developers express a business intent without forcing them to reconstruct all the complexity of every participant in the chain.
The intent here is simple: verify this credential.
The infrastructure translates that intent into the available mechanism, but it must preserve enough traceability for the developer to understand the result.
This balance matters: simplify the happy path without hiding the problematic path.
APIs that expose all the processor's complexity make integration difficult. APIs that hide too much information make incidents difficult to diagnose.
A useful abstraction sits between these two extremes.
What should be observed?
Zero Auth can also be treated as an observable event in the credential lifecycle.
An operation can track verification volume, result distribution, technical failures, latency, timeouts, and behavior by route when those data are available and can be used appropriately.
It is also possible to relate initial verification to later lifecycle events without confusing correlation with causation.
Observability turns Zero Auth from an isolated API call into an understandable stage of the infrastructure.
When does it make sense to consider Zero Auth?
Zero Auth tends to be relevant when a credential needs to be verified before later financial use.
This occurs in onboarding, card-on-file, trials, subscriptions, marketplaces, and services where payment method registration and charging happen at different times.
The decision, however, should start with the problem, not the technology.
If the question is “do we need to verify this credential before using it in the future?”, Zero Auth can be part of the solution.
If the need is to authenticate the cardholder, assess fraud, protect data, or increase resilience, other layers need to be considered.
Choosing the right technology starts with naming the problem correctly.
Is Zero Auth required to save a card?
We should not turn Zero Auth into a universal requirement for every card-on-file architecture.
Implementation depends on the product, architecture, participants, and available capabilities.
The important point is to separate the concepts. Saving a representation of a credential and verifying a credential are different operations. One journey may combine them; another may have different needs.
Technical documentation should be the reference for the implementation's actual behavior.
From verification to charging: think in states, not just APIs
Zero Auth's main lesson is not about the zero amount. It is about separating states.
A registered credential is not necessarily a verified credential. A verified credential is not an authorized purchase. An authorized purchase is not necessarily captured. A capture is not necessarily settled. A technical failure is not necessarily a financial decision.
When these states are treated as equivalent, systems become more fragile.
When they are explicitly modeled, the operation gains the ability to diagnose, automate, and evolve.
At AZPay, Zero Auth is a documented platform feature. The documentation describes the sandbox endpoint, request fields, response examples, return codes, verification flow, and next steps related to tokenization, subscriptions, and fraud prevention.
The more interesting architectural question, therefore, is not just whether a Zero Auth API exists.
It is: at which stage of the credential lifecycle should this verification take place, and what will our system do with the result?
That is the difference between adding an API call and designing payment infrastructure.
Documentation and references
AZPay — Zero Auth: https://docs.azpay.com.br/pt-BR/docs/features/zero-auth
This is the main implementation reference used in this article. The documentation describes Zero Auth as a nonmonetary preauthorization, presents the flow between merchant, AZPay, acquirer, and issuer, and documents the sandbox endpoint, request fields, response examples, and return codes. It also puts its use alongside tokenization, subscriptions, and fraud prevention into context. This article's sections on how Zero Auth works at AZPay, reversal, response interpretation, and retry strategy were based on that documentation.
AZPay — technical documentation: https://docs.azpay.com.br/pt-BR/
This is the entry point to the platform's current documentation. Use the current technical documentation as the source of truth for authentication, endpoints, payloads, testing, and implementation behavior, since APIs and capabilities may evolve after this article is published.
Visa — Payment Account Validation: https://developer.visa.com/docs/pav
Visa documents Account Verification as one of the Payment Account Validation methods and also describes it as a zero-amount authorization. The reference provides network-level context for the concept discussed in this article and shows that verifying an account before making services available, adding it to a wallet, or storing it as card-on-file is a recognized use case in card infrastructure.
Visa — How to Use Payment Account Validation: https://developer.visa.com/capabilities/pav/docs-how-to
This reference details Account Verification as a zero-amount authorization request used to check an account's status. It supports this article's central distinction between verifying a credential and performing a financial charge.
Visa — Account Verification with a Zero Amount Authorization: https://developer.visaacceptance.com/docs/vas/en-us/payments/developer/ctv/rest/payments/payments-processing-basic-intro/payments-processing-basic-zero-auth-intro.html
Visa Acceptance's documentation describes zero-amount authorization as an account verification practice and explicitly states that a zero-amount authorization cannot be captured. The reference helps explain why verification and capture must be treated as different states and intentions.
This article is educational. Network rules, route support, requirements, and API behavior may evolve; for implementation, always validate the current technical documentation and the rules applicable to your environment.