Question 1

What is the Token Requestor Service (Issuer Wallet)?

Accepted Answer

The Token Requestor Service is an end-to-end solution that enables banks, fintechs, and financial institutions to build secure and flexible NFC (contactless) payments directly within their own Mobile Banking or Payment App. It effectively allows you to create your own "Issuer Wallet," giving you a standalone digital payment ecosystem independent of third-party wallets like Apple Pay or Google Pay.

Question 2

How does an Issuer Wallet differ from Apple Pay or Google Pay?

Accepted Answer

An Issuer Wallet is a proprietary, white-label alternative to Apple Pay and Google Pay. The key difference is control: with an Issuer Wallet, you retain full control over the user experience (UX), the payment flow, and the token lifecycle without relying on third-party wallet providers.
(Note: Cards managed exclusively within the Issuer Wallet infrastructure cannot simultaneously be added to Apple Pay or Google Pay, and vice versa).

Question 3

What are the main components of the Token Requestor Service?

Accepted Answer

Wallet Server (Backend): A certified backend system integrated with Mastercard (MDES) and Visa (VTS). It acts as the Token Requestor on behalf of the issuer and manages card digitization, provisioning, and token lifecycles.
Android & iOS SDK’s: A fully EMVCo-compliant library for managing NFC transactions and token lifecycles natively on Android and iOS
Wearables SDK: A dedicated SDK enabling tokenized NFC payments on smartwatches (e.g., Huawei).

Question 4

What domains does the Wallet Server manage?

Accepted Answer

The Wallet Server securely manages the entire hierarchy of your digital payment ecosystem:
User: Identified via a unique session and external ID.
Device: Tracks the specific physical device paired with the user.
Card: The funding source securely stored ("Whole PAN is stored on Wallet Server (always or short period of time).
Payment Token: The active, inactive, or suspended digital credential residing on the device.

Question 5

Do I need my own connections to Mastercard or Visa?

Accepted Answer

Yes. To tokenize payment cards, the token requestor (the bank or fintech) must have active connectivity and access configurations with Mastercard (MDES) or Visa (VTS). Verestro’s backend leverages these connections to provision the tokens.

Question 6

Is it possible to replace parts of the Verestro ecosystem with our own components?

Accepted Answer

While the fastest integration path is using the complete Verestro ecosystem (SDKs + Wallet Server + Token Management Platform), the architecture is modular. For example, it is possible to use a different Token Management Platform, or adapt your own backend to work with the Verestro SDKs, provided the proper compliance and API adaptations are met.

Question 7

Can a user pair multiple smartwatches to one smartphone?

Accepted Answer

No. A smartphone can only have one active smartwatch connected for payment purposes at a time. Pairing a new smartwatch will disconnect the previously active one.

Question 8

Is the Verestro Issuer Wallet secure?

Accepted Answer

Absolutely. The entire infrastructure is fully compliant with global security standards, including PCI Data Security Standard (PCI DSS) and EMVCo. Furthermore, the service is regularly audited by accredited organizations on behalf of Mastercard and Visa.

Question 9

What happens to the tokens if a device or smartwatch is lost?

Accepted Answer

Because you have full control over the Token Lifecycle, tokens can be instantly suspended or deleted. In the case of a lost smartwatch or phone, the device can be remotely "unpaired" and tokens revoked via your mobile application's backend or your Customer Service portal. Once removed, no transactions initiated from that lost device will be authorized.

Question 10

What are the tokenization decision paths?

Accepted Answer

During the digitization process, the system enforces security rules and returns one of three decisions:
Green (Approved): The digitization request is safe and approved without further cardholder interaction.
Yellow (Require Additional Authentication): The request is approved, but the cardholder must authenticate via a secondary method (like an SMS OTP) before the token is activated.
Red (Declined): The digitization request failed risk checks and is declined.

Successfully implemented with

Success stories

General information

CERTIFIED & COMPLIANT

Key Advantages & Features

Independent Ecosystem

Data Privacy & Security

Cost Efficiency

Contactless & Wearable Support

E-Commerce Readiness

Technical Specifications & Compliance

Cross-Platform Mobile Integration

Server-Side Tokenization Management

Certified Network Tokenization

Advanced Contactless Technology

Top-Tier Security Compliance

Infrastructure flow

How can it work for your business?

Frequently asked questions