Activate Card (With Validation Rules)
Activates a customer's card using comprehensive validation rules including card details, customer personal information, and optional OTP/PIN verification.
Validation Fields (in rule object)
| Field | Required | Description |
|---|---|---|
cardLastSix | ✅ | Last 6 digits of card number |
expiryDate | ✅ | Card expiry (MM/YY) |
cvv | ✅ | Card CVV |
customerFirstName | ✅ | Must match registered name |
customerLastName | ✅ | Must match registered name |
customerDob | ✅ | Must match DOB (DD/MM/YYYY) |
govtId | ✅ | PAN number |
otp | Optional | OTP if OTP-based activation |
traceNumber | Optional | From Generate OTP (required with OTP) |
pin | Optional | PIN if PIN-based activation |
email | Optional | Customer email |
kitNumber | Optional | Kit number for additional validation |
When to Use (vs Basic Activate)
Use this endpoint when your product requires comprehensive identity verification before card activation (e.g., high-value cards, full KYC products).
Authorization
bearerAuth tenantId JWT Bearer token from the Authentication API
In: header
Your unique tenant identifier assigned during onboarding
In: header
Header Parameters
Your unique tenant identifier
Request Body
application/json
Required. Customer entity ID
Kit number
Validation rules for card activation
Response Body
application/json
application/json
application/json
curl -X POST "https://sandbox-api.m2pprepaid.com/prepaid/customer/v1/customers/activate-card" \ -H "X-TENANT-ID: ACME_CORP" \ -H "Content-Type: application/json" \ -d '{ "entityId": "615928984620006085281025", "mobile": { "value": "9876543210", "countryCode": 91 }, "kitNumber": "20006085", "rule": { "cardLastSix": "000411", "expiryDate": "08/27", "cvv": "079", "customerFirstName": "Sidney", "customerMiddleName": "King", "customerLastName": "Sheldon", "customerDob": "05/08/1987", "govtId": "AMXPC9888A", "email": "", "pin": "", "otp": "", "traceNumber": "" } }'{
"result": {
"message": "Card Activated Successfully"
},
"pagination": null
}{
"type": "https://www.m2pfintech.com/problem/problem-with-message",
"title": "Bad Request",
"status": 400,
"detail": "Unable to convert http message",
"message": "error.http.400"
}{
"type": "https://www.m2pfintech.com/problem/problem-with-message",
"title": "Card has been activated previously",
"status": 409,
"detail": "Card has been activated previously",
"message": "error.business",
"businessCode": "PPCUST_075"
}Activate Card (Basic) POST
Activates a customer's card using basic validation: card last 6 digits, CVV, and expiry date. This is the simpler activation flow — for more comprehensive validation, use the Activate Card with Rules endpoint. ### Prerequisites - Card must be in `ALLOCATED` status - Customer must have the physical card to provide CVV and last-6 digits ### Post-Activation - Card status changes from `ALLOCATED` → `ACTIVE` - Customer can immediately start transacting
Perform Card Action (Unified API) POST
A unified API to perform various card actions. This is the **maker** step in the maker-checker workflow — the request is created and may require approval before execution. ### Supported Actions (requestStatus) | Action | Description | |--------|-------------| | `ACTIVE` | Activate a newly issued card | | `LOCKED` | Temporarily lock a card | | `UNLOCKED` | Unlock a previously locked card | | `BLOCKED` | Permanently block a card | | `REPLACED` | Replace a damaged/lost card | | `UPDATE_PREFERENCE` | Update card transaction preferences | ### Maker-Checker Flow 1. **Create Request** (this API): Creates a card action request with `currentStatus: CREATED` 2. **Approve/Reject** (State Transition API): Authorized user approves or rejects the request 3. **Execution**: Approved requests are automatically processed ### When to Use Use this API when your organization requires **approval workflows** for card operations. For direct card operations without approval, use the simpler Card Status Update API. ### reasonCode in Maker-Checker - Provide `reasonCode` + `reasonMsg` for actions with card-usage impact: `LOCKED`, `UNLOCKED`, `BLOCKED`, `REPLACED`. - For `UPDATE_PREFERENCE`, use policy-centric codes like `LIMIT_TUNING`, `RISK_POLICY_UPDATE`, `CUSTOMER_REQUEST`. - `requestStatus` drives execution; `reasonCode` is for audit/reporting and operational context.