--- title: 3DS in P1 slug: concepts/cards/issuing-models/integrated-issuing/online-authentication/3DS-in-P1 description: EMV 3DS authentication platform for Visa Secure and Mastercard SecureCode with SCA, risk-based approvals, OTP/biometric challenges, and VCAS validation. docTags: createdAt: 2026-03-12T09:22:44.516Z --- # 3DS overview The 3D Secure (3DS) authentication system provides an additional security layer for card-not-present transactions through Strong Customer Authentication (SCA). The system supports both rules-based decisioning and multiple authentication methods to verify cardholder identity during online purchases. **Supported Networks:** - Visa (Visa Secure) - Mastercard (Mastercard SecureCode®) **Authentication Standard:** Strong Customer Authentication (SCA) compliant **Note:** Both Mastercard and Visa support EMV® 3D Secure. ## Quick reference ### Authentication types OTP (One-Time Password) is a temporary, single-use, secure code. The system sends it via SMS to the customer's mobile phone or email. For OTP-based authentication, OTPSMS or OTPEMAIL, you must provide customer contact information as follows: - **Mobile number:** Retrieve this during card creation. It must be the customer’s verified mobile phone number. See the `phoneNumber` attribute in the [Create new card](docId\:EJCciNVxb0oMKjA567gUM) API endpoint for the required format. - **Email address:** Retrieve this during card creation. It must be the customer’s verified email address. See the `emailAddress` attribute in the [Create new card](docId\:EJCciNVxb0oMKjA567gUM) API endpoint for the required format. | Type | Description | Validation Required | Use Case | | -------------- | --------------- | ------------------- | -------------------------- | | OTPSMS | SMS OTP | ❌ No (automatic) | Standard e-commerce | | OTPEMAIL | Email OTP | ❌ No (automatic) | Standard e-commerce | | OUTOFBANDOTHER | Biometric (OOB) | ✅ Yes (manual) | Mobile app with biometrics | ### API endpoints summary | Endpoint | Method | Purpose | | -------------------------------------------------------------- | ------ | ------------------------------------------------- | | [/v1/3ds/\{id}](docId\:Su5NVsUfruWN28v1O7gM8) | GET | Get authentication details | | [/v1/3ds/\{id}/validate](docId:0-MnW4CrKX4T_GPrujleW)
| POST | Validate OOB authentication (OUTOFBANDOTHER only) | | [/v1/simulate/3ds/authenticate](docId\:VDmgALvyG_2Gld_bUaJXf) | POST | Simulate 3DS authentication (testing) | ### Important notes **Authentication flow:** ```mermaid sequenceDiagram participant Merchant participant P1 as Cross River P1 participant Partner participant Cardholder Note over Merchant,Cardholder: 3DS Authentication Flow Merchant->>P1: 1. Initiate 3DS authentication request P1->>P1: 2. Evaluate authentication rules alt Approve P1->>Merchant: Transaction Approved else Decline P1--xMerchant: Transaction Declined else Challenge Required P1->>Partner: 3. Send authentication webhook
(based on authentication type) Note over Partner,Cardholder: Partner Configuration Applied Partner->>Cardholder: 4. Partner uses webhook from Cross River
to present authentication options Cardholder->>Cardholder: 5. Complete authentication Cardholder->>Partner: 6. Authentication result Partner->>P1: 7. Return authentication response P1->>Merchant: 8. Final transaction result end ``` 1. Merchant initiates 3DS authentication request 2. Cross River P1 evaluates rules (Approve/Decline/Challenge) 3. If challenge triggered, Cross River P1 sends webhook to partner (based on authentication type) 4. Cardholder presented with configured authentication options 5. Authentication method executes based on partner configuration **Validation requirements:** - **OUTOFBANDOTHER requires validation:** After biometric authentication completes, merchant **must** call [POST /v1/3ds/\{id}/validate](docId:0-MnW4CrKX4T_GPrujleW) to send result back to P1 - **OTPSMS and OTPEMAIL are automatic:** No validation endpoint call required. VCAS handles OTP validation internally ## Three-domain model 3DS authentication involves three separate domains: | Domain Type | Description | | ------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | :::Heading{depth="3" indent="1"} Acquirer (merchant) ::: | - Merchant's e-commerce platform - Initiates authentication request - Receives authentication results | | :::Heading{depth="3" indent="1"} Issuer (Cross River P1) ::: | - Access Control Server (ACS) - Processes authentication requests - Sends authentication challenges | | :::Heading{depth="3" indent="1"} Interoperability (VCAS) ::: | - VCAS (Visa Card Authentication Service) - Routes messages between domains - Validates authentication results - Handles both Visa and Mastercard authentication flows - Generates CAVV tokens | ## Authentication methods ### Method 1: Out of Band (OOB) authentication **Type:** OUTOFBANDOTHER **Flow:** ```mermaid sequenceDiagram participant Merchant participant P1 as Cross River P1 participant Partner participant Cardholder Note over Merchant,Cardholder: 3DS Authentication Flow - Challenge Required Merchant->>P1: 1. Initiate 3DS authentication request P1->>P1: 2. Evaluate authentication rules Note over P1: Challenge triggered P1->>Partner: 3. Send authentication webhook
with authentication details Note over Partner: Partner uses webhook from Cross River Partner->>Cardholder: 4. Push notification to
cardholder's mobile app Cardholder->>Cardholder: 5. Authenticate using biometrics
(fingerprint, Face ID, etc.) Cardholder->>Partner: 6. Authentication completed Partner->>P1: 7. POST /v1/3ds/{id}/validate
Send authentication result P1->>P1: 8. Process and confirm authentication
(VCAS validation) P1->>Merchant: 9. Return final authentication result
with CAVV and ECI Note over Merchant,P1: Result: Authentication successful
Transaction approved ``` 1. Merchant initiates 3DS authentication request 2. Cross River P1 evaluates authentication rules 3. If P1 triggers a challenge, P1 presents the cardholder with configured authentication options (based on partner configuration) 4. P1 initiates authentication webhook to partner with authentication details 5. Partner receives webhook and pushes notification to cardholder's mobile app 6. Cardholder authenticates using biometrics (fingerprint, Face ID, etc.) in the app 7. Partner sends authentication result to Cross River P1 via the[Validate OUTOFBANDOTHER](docId:0-MnW4CrKX4T_GPrujleW)** **API endpoint. 8. P1 confirms authentication with VCAS (Visa Card Authentication Service) 9. P1 returns final authentication result with CAVV and ECI to merchant **Timeout:** 10 minutes for cardholder response **Advantages:** - Frictionless user experience - Biometric authentication - No manual code entry **Important:** This method **requires** calling the /validate endpoint to send the authentication result back to P1. ### Method 2: One-Time Passcode (OTP) authentication SMS OTP **Type:** OTPSMS **Flow:** ```mermaid sequenceDiagram participant Merchant participant P1 as Cross River P1 participant Partner participant Cardholder Note over Merchant,Cardholder: 3DS Authentication Flow - OTP Challenge Merchant->>P1: 1. Initiate 3DS authentication request P1->>P1: 2. Evaluate authentication rules Note over P1: Challenge triggered P1->>Partner: 3. Send authentication webhook
with OTP details Note over Partner: Partner uses webhook from Cross River Partner->>Cardholder: 4. Trigger OTP delivery via SMS
to cardholder's phone Merchant->>Cardholder: 5. Display OTP entry screen Cardholder->>Merchant: 6. Enter OTP on
merchant's validation screen Merchant->>P1: 7. Submit OTP for validation P1->>P1: 8. Validate OTP automatically
(VCAS validation) P1->>Merchant: 9. Return authentication result
with CAVV and ECI Note over Merchant,P1: Result: Authentication successful
Transaction approved ``` 1. Merchant initiates 3DS authentication request 2. Cross River P1 evaluates authentication rules 3. If P1 triggers a challenge, cardholder is presented with configured authentication options (based on partner configuration) 4. Cross River P1 initiates authentication webhook to partner with OTP details 5. **Partner triggers OTP delivery via SMS to cardholder's phone** 6. Merchant displays OTP entry screen to cardholder 7. Cardholder enters OTP on merchant's validation screen 8. VCAS validates OTP automatically (no /validate endpoint call needed) 9. Cross River P1 returns authentication result with CAVV and ECI **No validation endpoint required** - OTP validation happens automatically within VCAS. **Important:** Partner is responsible for sending the OTP via SMS based on details received in webhook. Email OTP **Type:** OTPEMAIL **Flow:** ```mermaid sequenceDiagram participant Merchant participant P1 as Cross River P1 participant Partner participant Cardholder Note over Merchant,Cardholder: 3DS Authentication Flow - Email OTP Challenge Merchant->>P1: 1. Initiate 3DS authentication request P1->>P1: 2. Evaluate authentication rules Note over P1: Challenge triggered P1->>Partner: 3. Send authentication webhook
with OTP details Note over Partner: Partner uses webhook from Cross River Partner->>Cardholder: 4. Trigger OTP delivery via email
to cardholder's email address Merchant->>Cardholder: 5. Display OTP entry screen Cardholder->>Merchant: 6. Enter OTP on
merchant's validation screen Merchant->>P1: 7. Submit OTP for validation P1->>P1: 8. Validate OTP automatically
(VCAS validation) P1->>Merchant: 9. Return authentication result
with CAVV and ECI Note over Merchant,P1: Result: Authentication successful
Transaction approved ``` 1. Merchant initiates 3DS authentication request 2. Cross River P1 evaluates authentication rules 3. If challenge is triggered, cardholder is presented with configured authentication options (based on partner configuration) 4. Cross River P1 initiates authentication webhook to partner with OTP details 5. **Partner triggers OTP delivery via email to cardholder's email address** 6. Merchant displays OTP entry screen to cardholder 7. Cardholder enters OTP on merchant's validation screen 8. VCAS validates OTP automatically (no /validate endpoint call needed) 9. Cross River P1 returns authentication result with CAVV and ECI **No validation endpoint required. **OTP validation happens automatically within VCAS. **Important:** Partner is responsible for sending the OTP via email based on details received in webhook. **OTP Validity:** 10 minutes per code | Retry Logic | Resend Logic | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | - Maximum 3 attempts to enter correct OTP - Reference code displayed to confirm expected OTP - Authentication fails after 3 incorrect attempts - **Important:** PAN (Primary Account Number) remains active after failed attempts | * Initial OTP sent automatically * Up to 2 additional resends permitted (3 total OTPs maximum) * Each resend generates a new OTP code * Resend button becomes inactive after limit reached | ## Authentication rules system Authentication rules provide a control layer for 3DS decisioning by allowing custom logic based on transaction attributes. ### Purpose - Add custom decisioning logic to 3DS authentication flow - Works with both Cross River P1 decisioning and partner custom decisioning - Enforce stricter controls beyond base decisioning ### Key limitation Rules only enforce stricter controls or maintain existing declines. They cannot override declines. ## Authentication decision flow ### Step-by-step process ```mermaid sequenceDiagram participant Merchant participant P1 as Cross River P1 participant Partner participant Cardholder Note over Merchant,Cardholder: 3DS Authentication Flow Merchant->>P1: 1. Initiate 3DS authentication request P1->>P1: 2. Evaluate authentication rules alt Approve P1->>Merchant: Transaction Approved else Decline P1--xMerchant: Transaction Declined else Challenge Required P1->>Partner: 3. Send authentication webhook
(based on authentication type) Note over Partner: Partner uses webhook from Cross River Partner->>Cardholder: 4. Present authentication options Cardholder->>Cardholder: 5. Complete authentication
(method based on partner config) Cardholder->>Partner: 6. Authentication result Partner->>P1: 7. Return authentication response P1->>Merchant: 8. Final transaction result end ``` :::BlockQuote 1. Merchant Initiates 3DS Authentication Request ↓ 2\. P1 Receives Authentication Request ↓ 3\. All Active Rules Evaluate Simultaneously ↓ 4\. Each Rule Checks Transaction Attributes ↓ 5\. Matching Rules Execute Actions (Approve/Decline/Challenge) ↓ 6\. Apply "Most Restrictive" Decision Logic ↓ 7\. If CHALLENGE triggered: ├─ P1 initiates authentication webhook to partner ├─ Cardholder presented with configured authentication options └─ Authentication method (OTPSMS/OTPEMAIL/OUTOFBANDOTHER) executes ↓ 8\. Authentication Result ├─ For OTP methods: VCAS validates OTP automatically └─ For OOB methods: Partner calls /validate endpoint ↓ 9\. P1 Confirms with VCAS (Visa Card Authentication Service) ↓ 10\. Final Authentication Response (with CAVV and ECI) ↓ 11\. Response Transmitted to Merchant ::: ## Decision logic - "most restrictive" principle The system applies the **strictest outcome** among all matching rules: ### Decision priority (most to least restrictive): 1. **Decline:** Transaction rejected immediately 2. **Challenge:** Additional verification required 3. **Approve: **Transaction proceeds (if no rules triggered) ### Rules interaction ```mermaid flowchart TD A[Transaction Received] --> B{Evaluate All Rules} B --> C{Any Rule Declines?} C -->|Yes| D[❌ Transaction Declined] D --> E[Cannot Be Overridden] C -->|No| F{Any Rule Triggers Challenge?} F -->|Yes| G{Another Rule Declines?} G -->|Yes| D G -->|No| H[⚠️ Challenge Flow Continues] F -->|No| I{Any Rules Match?} I -->|No| J[🔄 Default Decisioning Applies] I -->|Yes| K[✅ Process Matched Rules] style D fill:#f44336,color:#fff,stroke:#b71c1c style E fill:#f44336,color:#fff,stroke:#b71c1c style H fill:#ff9800,color:#fff,stroke:#e65100 style J fill:#2196f3,color:#fff,stroke:#0d47a1 style K fill:#4caf50,color:#fff,stroke:#1b5e20 ``` - If **any rule declines** → Transaction is **declined** (cannot be overridden) - If **any rule triggers challenge** → Challenge flow continues (unless another rule declines) - If **no rules match** → Default decisioning applies ### Example scenario **Rules configured:** - Rule A: Challenge when risk score > 600 - Rule B: Decline when risk score > 800 **Transaction with risk score 850:** 1. Rule A matches → Action: Challenge 2. Rule B matches → Action: Decline 3. **Result:** Transaction **DECLINED** (decline is more restrictive than challenge) **Transaction with risk score 700:** 1. Rule A matches → Action: Challenge 2. Rule B does NOT match 3. **Result:** Transaction **CHALLENGED** (cardholder must authenticate) ## Available actions Authentication rules can execute two actions: ### 1. Decline - **Effect:** Reject the transaction immediately - **Use Case:** High-risk transactions, blocked merchants, suspicious patterns - **Result:** Transaction fails 3DS authentication ### 2. Challenge - **Effect:** Trigger additional verification flow (OTP or OOB) - **Use Case:** Medium-risk transactions requiring cardholder verification - **Result:** Cardholder must authenticate to proceed ## Authentication result codes ### Success states - **SUCCESS:** Cardholder authenticated successfully - **APPROVED:** Authentication approved by issuer ### Failure states - **FAILURE:** Authentication failed (incorrect OTP, biometric rejection) - **TIMEOUT:** Cardholder did not respond within 10 minutes - **CHALLENGE\_REQUIRED:** Additional verification needed - **DECLINED:** Authentication declined by rules engine ## Use cases ### Use case 1: E-commerce purchase - low risk (frictionless) **Scenario:** Customer purchases $50 item from known merchant **Flow:** ```mermaid sequenceDiagram participant Merchant participant P1 as Cross River Merchant->>P1: 1. Initiate 3DS authentication request P1->>P1: 2. Evaluate rules
Risk score: 450 (low) Note over P1: 3. No rules match
No challenge triggered P1->>P1: 4. Approve authentication
without cardholder interaction P1->>Merchant: 5. Return authentication result
with CAVV and ECI Note over Merchant,P1: Result: Frictionless approval
(no authentication challenge required) ``` Merchant initiates 3DS authentication request 1. P1 evaluates rules - Risk score: 450 (low) 2. No rules match - No challenge triggered 3. P1 approves authentication without cardholder interaction 4. P1 returns authentication result with CAVV and ECI 5. **Result:** Frictionless approval (no authentication challenge required) ### Use case 2: E-commerce purchase - medium risk **Scenario:** Customer purchases $500 item from new merchant **Flow:** ```mermaid sequenceDiagram participant Merchant participant P1 as Cross River participant Partner participant Cardholder participant VCAS Merchant->>P1: 1. Initiate 3DS authentication request P1->>P1: 2. Evaluate rules
Risk score: 650 (medium) Note over P1: 3. Rule matches:
"Challenge when risk_score > 600" P1->>Partner: 4. Send authentication webhook
with OTP details Partner->>Cardholder: 5. Present authentication options
(SMS OTP, Email OTP) Cardholder->>Partner: 6. Select SMS OTP Partner->>Cardholder: 7. Send OTP via SMS
to cardholder's phone Cardholder->>Merchant: 8. Enter correct OTP
on merchant's screen Merchant->>VCAS: 9. VCAS validates OTP automatically VCAS->>P1: 10. Confirm authentication P1->>Merchant: 11. Return CAVV and ECI Note over Merchant,VCAS: Result: Authentication successful
Transaction approved ``` 1. Merchant initiates 3DS authentication request 2. Cross River P1 evaluates rules - Risk score: 650 (medium) 3. Rule matches: "Challenge when risk\_score > 600" 4. Cross River P1 initiates authentication webhook to partner with OTP details 5. Cardholder presented with authentication options (SMS OTP, Email OTP) 6. Cardholder selects SMS OTP 7. **Partner sends OTP via SMS to cardholder's phone** (based on webhook data) 8. Cardholder enters correct OTP on merchant's screen 9. VCAS validates OTP automatically 10. Cross River P1 confirms with VCAS and returns CAVV 11. **Result:** Authentication successful, transaction approved ### Use case 3: E-commerce purchase - high risk **Scenario:** Customer purchases $1,000 item, cross-border transaction **Flow:** ```mermaid sequenceDiagram participant Merchant participant P1 as Cross River Merchant->>P1: 1. Initiate 3DS authentication request P1->>P1: 2. Evaluate rules
Risk score: 850 (high) Note over P1: 3. Rule matches:
"Decline when risk_score > 800" P1->>P1: 4. Apply "Most Restrictive"
decision logic P1--xMerchant: 5. Transaction declined Note over Merchant,P1: Result: Transaction declined immediately
(no challenge triggered,
no authentication required) ``` 1. Merchant initiates 3DS authentication request 2. P1 evaluates rules - Risk score: 850 (high) 3. Rule matches: "Decline when risk\_score > 800" 4. Apply "Most Restrictive" decision logic 5. **Result:** Transaction declined immediately (no challenge triggered, no authentication required) ### Use case 4: OOB authentication (OUTOFBANDOTHER) **Scenario:** Customer uses partner's mobile app with biometric support **Flow:** ```mermaid sequenceDiagram participant Customer as Customer
(Cardholder) participant Merchant participant P1 as Cross River P1 participant Partner Note over Customer,Partner: 3DS Authentication Flow - OOB Biometric Customer->>Merchant: 1. Initiate $300 purchase
in mobile app Merchant->>P1: 2. Initiate 3DS authentication request P1->>P1: 3. Evaluate authentication rules
Medium risk, challenge triggered P1->>Partner: 4. Send authentication webhook
with OOB biometric details P1->>Merchant: 5. Return authenticationId
and transactionId Note over Partner: Partner uses webhook from Cross River Partner->>Customer: 6. Send push notification
to mobile device Customer->>Customer: 7. Authenticate with Face ID
in partner's app Customer->>Partner: 8. Authentication completed Partner->>P1: 9. POST /v1/3ds/{id}/validate
status: "SUCCESS" P1->>P1: 10. Confirm authentication
(VCAS validation) P1->>Merchant: 11. Return CAVV and ECI Note over Customer,P1: Result: Frictionless authentication
Transaction approved ``` 1. Customer initiates $300 purchase in mobile app 2. Merchant initiates 3DS authentication request 3. P1 evaluates rules - Medium risk, challenge triggered 4. Cardholder presented with authentication options (partner configured for OOB biometric) 5. P1 initiates authentication webhook to partner 6. P1 returns `authenticationId` and `transactionId` to merchant 7. Partner receives webhook and sends push notification to customer's mobile device 8. Customer authenticates with Face ID in partner's app 9. **Partner **calls [POST /v1/3ds/\{id}/validate](docId:0-MnW4CrKX4T_GPrujleW)** **with status: "SUCCESS" to send result to P1 10. P1 confirms with VCAS and returns CAVV and ECI 11. **Result:** Frictionless authentication, transaction approved