Configure activation methods

An activation profile defines a verification method, such as SMS OTP, email OTP, issuer-app verification, or a contact-centre call. Agree the supported methods with the implementations team for your scheme and wallets. Each step-up rule selects its own profiles, including the default fallback.

Contact data and delivery

For contact-based methods, agree the source of the masked cardholder contact details: your Paymentology CMS or an issuer-hosted contact-data service. The masked value helps the cardholder recognize the destination. Your systems use their own contact records to deliver messages; a masked number is not a delivery address.

Paymentology forwards OTPs to the issuer. The issuer sends them to cardholders through the selected channel. For a static contact-centre number, website, or app target, supply the configuration appropriate to that method.

Mastercard

Support depends on the requestor and use case; the table is not a requirement to enable every method. During provisioning, Lume Token returns applicable methods in RAM.

Visa

Visa obtains methods through Retrieve Step-Up Methods. Configure provisioning decisions and method selection as separate steps in the same cardholder journey.

Jaywan

Agree the ID&V methods for the programme's wallets. For Jaywan v1.2, provisioning returns the method list. Send Selected Validation Method identifies the selected method and supplies the OTP for issuer delivery. See the Jaywan guide.

Complete app or contact-centre verification

After your app or contact-centre agent successfully verifies the cardholder for an approved, provisioned token awaiting activation, call Token Activate. Use the credentials and connection setup for your Paymentology API integration, not your notification receiver credentials.

1. Identify the funding card and the specific network token from the notification context.
2. Complete your selected cardholder-verification process.
3. Submit Token Activate with reasonCode: "A" for successful authentication, or "C" when a customer-service agent authenticated the cardholder.
4. Inspect the API response for errors and track the resulting TNR lifecycle event. Sending the request or acknowledging an earlier notification is not proof of activation.

For tspToken, use Mastercard's tokenUniqueReference for the token being activated, Visa's ADDITIONAL_MESSAGE_DATA.tokenReferenceID, or Jaywan's virtualCardId. The exact Mastercard nesting depends on the event: for example, fundingAccountInfo.tokenUniqueReference in NotifyServiceActivated and the top-level tokenUniqueReference in DeliverActivationCode.

The following synthetic request illustrates a Mastercard token verified by a contact-centre agent:

{
  "api_call_unique_identifier": "20261002000101",
  "client_id": 123456,
  "token": 123456789,
  "tspToken": "token-mc-example-001",
  "reasonCode": "C"
}

Follow the Token Activate reference for the endpoint, full response, optional fields, and scheme-specific requirements, including Visa's conditional activationCode field. If verification does not succeed, do not submit a successful-authentication reason. This activation call concerns provisioning; do not use it to represent authentication of an already active e-commerce token.

Validate the complete journey

Check that the wallet presents the intended methods, contact details identify the correct destination, your app or messaging service completes its part, and the token lifecycle reflects completion. Test the default fallback as well as explicit step-up rules.