Combining Services
After the customer is successfully authenticated, you must get authorization from the issuing bank to proceed with the transaction. While these are separate processes, link these services by immediately passing the returned values into a request to authorize the transaction. The two services can be linked when:
- Checking enrollment determines that no challenge is required. Pass the values returned from checking enrollment to the authorization request.
- Validating a challenge authenticates the cardholder. Pass the values returned from validating the challenge to the authorization request.
With the same request transactions, a different endpoint must be referenced for the authorization, and an additional element must be added to the JSON. When step-up authentication is required, transaction processing stops to allow completion of authentication, and authorization is not called until after the challenge response is validated. This integration method is recommended.
Depending on your card type, you might not receive the XID value. If you receive this field under a frictionless scenario, it is required for authorization.
Combining Check Enrollment and Authorization
Receiving certain responses from checking enrollment allows the authorization to be requested immediately afterwards. These checking enrollment responses allow immediate authorization:
- Successful frictionless authentication
- Attempted stand-in frictionless authentication
- Issuer does not support the payer authentication program
- Account is not eligible for a payer authentication program
- Unavailable frictionless authentication
- Failed frictionless authentication
- Rejected frictionless authentication
In all checking enrollment scenarios, integrate these services by combining the checking enrollment and authorization services into a single transaction. When the services are combined, one of these conditions occurs:
- No additional integration work is required to manually map the appropriate check enrollment results to the corresponding authorization request fields.
- If further authentication is needed, the authorization cannot happen until after authentication completes and you can proceed to the next steps for challenging.
With same request transactions, a different endpoint must be referenced for the authorization, and an additional element must be added to the JSON. Depending on your card type, you might not receive the XID value. If you receive this field under a frictionless scenario, it is required for authorization.
Enrollment check and authorization endpoint:
POST /risk/v1/authentications
POST /risk/v1/authentications
POST /risk/v1/authentications
Enrollment Check Response Fields and Their Equivalent Authorization Request Fields
When a customer is authenticated without a challenge, the transaction can be authorized either in the same request or in a separate authorization request. Whether authorization occurs in the same request or a separate request, the values from the check enrollment response must be passed to the authorization request to qualify for a liability shift. This table matches the check enrollment fields with their equivalent authorization fields. Sometimes a check enrollment response field is the same field used in the authorization request.
Include this card-specific information in your authorization request:
- For Visa, JCB, China UnionPay, Elo, Diners Club, Discover, and American Express — include the CAVV.
- For Mastercard only — include the collection indicator and the AAV (also known as UCAF).
| Identifier | Enrollment Check Response Field | Card Authorization Request Field |
|---|---|---|
| E-commerce indicator | consumerAuthenticationInformation.ecommerceIndicator | processingInformation.commerceIndicator |
| Collection indicator | consumerAuthenticationInformation.ucafCollectionIndicator | consumerAuthenticationInformation.ucafCollectionIndicator |
| CAVV | consumerAuthenticationInformation.cavv | consumerAuthenticationInformation.cavv |
| AAV | consumerAuthenticationInformation.ucafAuthenticationData | consumerAuthenticationInformation.ucafAuthenticationData |
| XID | consumerAuthenticationInformation.xid | consumerAuthenticationInformation.xid |
| Result of the enrollment check for Asia, Middle East, and Africa Gateway | consumerAuthenticationInformation.veresEnrolled | consumerAuthenticationInformation.veresEnrolled |
| 3-D Secure version | consumerAuthenticationInformation.specificationVersion | consumerAuthenticationInformation.paSpecificationVersion |
| Directory server transaction ID | consumerAuthenticationInformation.directoryServerTransactionId | consumerAuthenticationInformation.directoryServerTransactionId |
Combining Validation and Authorization
After the customer is successfully authenticated, you must get authorization from the issuing bank to proceed with the transaction. While these are separate processes, integrate these two services into a single process whenever possible. When you do so, no additional integration work is required on your part to manually map the appropriate validation results to corresponding authorization request fields.
With the same request transactions, a different endpoint must be referenced for the authorization, and an additional element must be added to the JSON. When step-up authentication is required, transaction processing stops to allow authentication to complete, and authorization is not called until after the challenge response is validated. Use this integration method whenever possible. Depending on your card type, you might not receive the XID value. If you receive this field under a frictionless scenario, it is required for authorization.
Validation and authorization endpoint:
POST /pts/v2/payments
POST /pts/v2/payments
POST /pts/v2/payments
Validation Fields and Their Equivalent Authorization Fields
When a customer is authenticated after a challenge, the transaction can be authorized in the same request or in a separate authorization request. Whether authorization is combined with validation or occurs in a separate request, the values from the validation response must be passed to the authorization request to qualify for a liability shift to the issuing bank. This table pairs the validation field with its equivalent authorization API field.
Include this card-specific information in your authorization request:
- For Visa, JCB, China UnionPay, Elo, Diners Club, Discover, and American Express — include the CAVV.
- For Mastercard only — include the collection indicator and the AAV (also known as UCAF).
| Identifier | Validation Check Response Field | Card Authorization Request Field |
|---|---|---|
| E-commerce indicator | consumerAuthenticationInformation.indicator | processingInformation.commerceIndicator |
| Collection indicator | consumerAuthenticationInformation.ucafCollectionIndicator | consumerAuthenticationInformation.ucafCollectionIndicator |
| CAVV | consumerAuthenticationInformation.cavv | consumerAuthenticationInformation.cavv |
| AAV | consumerAuthenticationInformation.ucafAuthenticationData | consumerAuthenticationInformation.ucafAuthenticationData |
| XID | consumerAuthenticationInformation.xid | consumerAuthenticationInformation.xid |
| 3-D Secure version | consumerAuthenticationInformation.specificationVersion | consumerAuthenticationInformation.paSpecificationVersion |
| Directory server transaction ID | consumerAuthenticationInformation.directoryServerTransactionId | consumerAuthenticationInformation.directoryServerTransactionId |
Thanks for your feedback!
Last published: September 29, 2026