What an On-Behalf-Of-Token Requestor Actually Does

Every network token in circulation exists because some entity, somewhere, asked a card scheme to issue it. Most merchants never make that request themselves. Instead, a payment service provider, gateway, or tokenization platform does it for them, acting in a role built directly into how card schemes run their token infrastructure: the On-Behalf-Of Token Requestor, or OBOTR. The pattern shows up across the major schemes' token programs, Visa Token Service, Mastercard's Digital Enablement Service, American Express's token service, even where the exact terminology and implementation details vary from one to the next.

New to network tokenization? To learn more about how network tokens work end to end, see our guide network tokenization.

What an OBOTR is

An OBOTR is an entity a card scheme has authorized to request and manage tokens on behalf of other parties, typically merchants, rather than only for itself. This matters because it gives a merchant working through that provider the same underlying connectivity to issuers that the provider itself has, without the merchant needing to establish that relationship directly. Mastercard is one of the few schemes to publish the mechanics of this role in real technical detail, so its MDES for Merchants documentation is the clearest public illustration of how an OBOTR program actually works, even though the same basic pattern of delegated token requesting exists across the other schemes too.

An OBOTR's work breaks down into three core jobs, and the rest of this piece follows that order. First, onboarding: bringing a merchant into the program and obtaining the token requestor identifier that merchant will operate under, the credential the OBOTR then uses to request tokens and, later, to fetch the cryptograms needed for cardholder-initiated transactions, the CITs where the customer is actively present in the flow. Second, lifecycle management: keeping every token it holds accurate as the underlying card changes over time. Third, transacting: actually using a token and its cryptogram to submit a payment for authorization. Each is a distinct, ongoing responsibility, not a one-time setup step.

How tokenization actually happens

A card doesn't enter the token system at just one moment, and an OBOTR has to account for all of them. Using Mastercard's documented scenarios as the illustration: tokenization can happen while a consumer is actively transacting, entering or selecting a card mid-checkout; it can happen when a consumer adds a card to their profile outside of a purchase, sometimes called add-card tokenization; and it can happen in bulk, converting an entire existing card-on-file repository into tokens with no consumer action involved at all. A provider running a real OBOTR operation, on any scheme, needs to support all three, not just the checkout-moment case that gets the most attention.

Underneath each of those scenarios sits a detail that's easy to miss: an OBOTR doesn't operate under a single identifier for every merchant it serves. Each merchant onboarded through the program gets its own scheme-issued token requestor identifier, and the OBOTR has to maintain an internal mapping between that merchant, its identifier, and the reference number returned for every token it creates. That reference is the working handle the OBOTR uses afterward, whichever scenario produced it: it's what gets submitted, alongside the correct identifier, whenever the provider later needs to retrieve payment credentials to actually process a transaction.

Keeping tokens working day to day

Across scheme implementations, the tokenize step and the payment step are deliberately separate calls. Tokenizing a card provisions the credential and returns a reference to it, but a usable payment credential isn't pulled until a separate request at the actual moment of payment. This split lets a provider provision a token in advance, at checkout or when a card is added, and only retrieve the sensitive, single-use payment data needed for authorization when a transaction actually happens, keeping that data out of storage between purchases.

That token then has to stay accurate for as long as it's in use, which is where lifecycle management comes in. Cards get reissued, accounts get closed, and card art changes, and schemes generally support two ways for an OBOTR to stay current on all of it. The first is push-based: a notification fires whenever one of these changes happens on the issuer's side, and the OBOTR acknowledges it and updates its own stored token state accordingly, which is the more convenient path since the provider doesn't have to go looking for changes itself. The second is pull-based: the OBOTR can separately request the current status of a specific token directly from the scheme, useful for reconciling state after an outage or simply confirming a token's details on demand. Both mechanisms are typically supported side by side rather than one replacing the other, and Mastercard's documentation reflects this: it recommends leaning on the push notifications to avoid unnecessary traffic, while still making direct status requests available for the cases where a provider needs to check in on its own terms. When an OBOTR finally processes an actual authorization, it retrieves the stored reference and identifier for the relevant token, requests the payment credential, and submits the result to an acquirer in place of a raw card number, which only works if that acquirer supports the scheme's tokenized-payment mechanism, Mastercard's documentation names Digital Secure Remote Payments specifically. A provider's token infrastructure and a merchant's acquiring relationship both have to support the same capability for a tokenized payment to actually clear.

To learn more about network token lifecycle management, read our guide.

A certified role, not just a convenience

Operating as an OBOTR isn't simply a matter of building the integration and starting to call the API. In Mastercard's program, a gateway must certify against a defined self-assessment questionnaire before it's authorized to run in this capacity, covering the tokenization flows, the lifecycle handling, and the security requirements the role depends on. It's a formal, audited role within the scheme's ecosystem, not an informal convenience one provider happens to offer, and it's reasonable to expect comparable certification requirements from other schemes' equivalent programs, even where the specific process differs.

None of this is something a merchant typically builds or operates directly, regardless of which scheme is involved. It's the work an OBOTR takes on so a merchant doesn't have to run multiple tokenization flows, handle event-driven lifecycle updates, and maintain a certified integration with each scheme's token service independently. Understanding what the role actually does, rather than treating it as an abstract line in a provider's documentation, is what makes it possible to ask a provider informed questions about how their tokenization actually works, on any scheme.

‍