API LibraryClick To Pay

Remove a card from Click to Pay

Remove a specific card/kit from the Visa Click to Pay network without removing the customer enrollment. The customer remains active on CTP with their other cards.

Validations:

Entity CTP status must be ACTIVE
Kit CTP status must be ACTIVE

Authorization

BearerAuth TenantHeader

AuthorizationBearer <token>

JWT Bearer token obtained from the /auth/login endpoint

In: header

TENANT<token>

Tenant identifier provided by M2P (e.g. ENBDTABBY)

In: header

Request Body

application/json

entityId*string

Entity identifier

kitNo*string

Kit number to remove from CTP

Response Body

`application/json`

`application/json`

curl -X POST "https://api.m2p.com/Yappay/click-to-pay/v1/removeKit" \  -H "Content-Type: application/json" \  -d '{    "entityId": "918c3ed3-5cb0-4c2e-a80d-b70e1594de4b",    "kitNo": "1234655"  }'

{
  "result": {
    "tenant": "ENBDTABBY",
    "entityId": "918c3ed3-5cb0-4c2e-a80d-b70e1594de4b",
    "requestTraceId": "651562ba-83cf-11ee-b962-0242ac120005",
    "event": "CTP_REMOVE_KIT"
  },
  "exception": null,
  "pagination": null
}

{
  "result": null,
  "exception": {
    "detailMessage": "Not a registered Customer",
    "shortMessage": "Not a registered Customer",
    "errorCode": "Y109",
    "languageCode": "en"
  },
  "pagination": null
}

Remove customer from Click to Pay POST

Remove a customer and all their enrolled cards from the Visa Click to Pay network. Use this when a cardholder opts out entirely or withdraws consent. The entity and all associated payment instruments transition to REMOVAL_IN_PROGRESS immediately and are set to REMOVED on successful webhook confirmation. Validations: 1. Entity must be registered on CTP 2. Entity CTP status must be ACTIVE

Register a new customer with card and wallet POST

Register and activate a customer in the prepaid program. This single API call creates a customer profile, issues a card (virtual or physical), and sets up a wallet. Field requirements are configuration-driven per tenant. Fields marked as Conditional depend on your tenant BusinessCustomFields settings including sor.model, customer.id.type, and unique.field configurations. For new card issuance, provide cardType as V (Virtual) or P (Physical). For activating a pre-printed card, provide the kitNo instead. Do not send both cardType and kitNo together for pre-printed card activation. If neither cardType nor kitNo is provided, the API returns an error. Idempotent on contactNo plus idNumber combination when tenant-level uniqueness check is enabled. Always Mandatory Fields - contactNo (always validated for uniqueness), business or businessType (at least one required), entityId. SOR Flow Dependent Fields - When SOR integration is enabled (sor.model = SOR_REG_REQUIRED or SOR_KYC_REQUIRED or SOR_KYC_OPTIONAL), firstName, lastName, gender, specialDate, emailAddress, address, city, state, pincode, kycStatus, programName, programType, and partnerCustomerId become mandatory. ID Validation - When BusinessCustomField customer.id.type is configured, idType and idNumber become mandatory. Validation rules apply per document type (e.g. Aadhaar uses Verhoeff algorithm). Uniqueness Validation - Configured via BusinessCustomField unique.field, controls how many registrations are allowed per contactNo or idNumber per day, month, year, or overall. Click to Pay Auto-Enrollment - When Click to Pay (CTP) is enabled for the tenant (BUSINESSCUSTOMFIELD click.to.pay.enable = Y|ALL), successful registration automatically triggers CTP enrollment with Visa. The CTP registration happens asynchronously and the customer's CTP status can be tracked via the CTP fetchEntityDetails or fetchRequestStatus APIs.