On This Page
Capture Context API
This section contains the information you need to request the capture context using the
capture context API.
The capture context request contains all of the merchant-specific parameters that tell the
frontend JavaScript library how to behave within your payment experience.
The capture context is a signed JSON Web Token (JWT) containing this information:
- Merchant-specific parameters that dictate the customer payment experience for the current payment transaction.
- A one-time public key that secures the information flow during the current payment transaction.
The capture context request includes these elements:
- allowedCardNetworks
- allowedPaymentTypes
- clientVersion
- targetOrigins
For information on JSON Web Tokens, see JSON Web Tokens.
- Target Origin
- The target origin is defined by the scheme (protocol), hostname (domain) and port number (if used).You must use the https:// protocol. Sub domains must also be included in the target origin.Any valid top-level domains, such as .com, .co.uk, and .gov.br, are supported. Wildcards are not supported.For example, if you are launchingClick to Payon example.com, the target origin could be any of the following:You can define the payment cards and digital payments that you want to accept in the capture context.
- Allowed Card Networks
- Use theallowedCardNetworksfield to define the card types.Click to Paysupports American Express, Mastercard, and Visa. TheClick to Pay Drop-In UImanually captures the other card types that are listed in the capture context request. This enables you to process the payment through the chosen gateway but the cardholder is not able to enroll these cards inClick to Pay.These card networks are available for card entry:
- American Express
- Carnet
- Cartes Bancaires
- China UnionPay
- Diners Club
- Discover
- EFTPOS
- ELO
- Jaywan
- JCB
- JCrew
- KCP
- mada
- Maestro
- Mastercard
- Meeza
- PayPak
- UATP
- Visa
To support dual-branded or co-badged cards, you must list your supported card types values for theallowedCardNetworksfield based on your preference for processing card numbers. For example, if a card is dual-branded as Visa and EFTPOS and EFTPOS is listed first, the card type is set to EFTPOS after the card number is entered in yourUnified Checkoutcard collection form. For information on dual-branded or co-badged cards, see Dual-Branded Cards.When a Cartes Bancaires dual-branded card is entered in theClick to Pay Drop-In UI, theClick to Pay Drop-In UIprovides a radio selector button to enable the cardholder to select which scheme they want to use to process the payment. The radio selector defaults to the card scheme that appears first in theallowedCardNetworksfield. - IMPORTANTSome card types, such as KCP and UATP, do not have security codes (CVV or CVN). If you include only card types that do not have security codes in theallowedCardNetworksfield,Unified Checkoutdoes not display the security code field in the UI.If you include card types that do not have security codes and cards types that do have security codes in theallowedCardNetworksfield,Unified Checkoutdisplays the security code field in the UI. The field is disabled in the UI when the cardholder enters a card number for a card type with no security code.
- Include Card Prefix
- You can control the length of the card number prefix to be received in the response to the capture context/sessionsrequest:
- 6 digits
- 8 digits
- no prefix at all
To specify your preferred card number prefix length, include or exclude theIMPORTANTWhen you request the card number prefix for aClick to Paytokenized credential, 6 digits are returned.Click to Paydoes not return 8 digits.transientTokenResponseOptions.includeCardPrefixfield in the capture context/sessionsrequest. - If you want to receive a 6-digit card number prefix in the response
- Do notinclude thetransientTokenResponseOptions.includeCardPrefixfield in the capture context/sessionsrequest.
- This example shows how a 6-digit card number prefix411111is returned in the transient token response:"maskedValue" : "XXXXXXXXXXXX1111”, "bin" : "411111"
- If you want to receive an 8-digit card number prefix in the response
- Include thetransientTokenResponseOptions.includeCardPrefixfield in the capture context request, and set the value totrue.IMPORTANTPer PCI DSS requirements, this requirement applies only to card numbers longer than 15 digits and for Discover, JCB, Mastercard, UnionPay, and Visa brands.
- If the card type entered is not part of these brands, a 6-digit card number prefix is returned instead.
- If the card type entered is not part of these brands but isco-brandedwith these brands, an 8-digit card number prefix is returned.
- This example shows how an 8-digit card prefix41111102is returned in the transient token response:"maskedValue" : "XXXXXXXXXXXX1111”, "prefix" : "41111102"
- If you do not want to receive a card number prefix in the response
- Include thetransientTokenResponseOptions.includeCardPrefixfield in the capture context request, and set the value tofalse.
- This example shows how a card number is returned without a card number prefix in the transient token response:"maskedValue" : "XXXXXXXXXXXX1111"
- Best practice:If your application does not require card number prefix information for routing or identification purposes,Cybersourcerecommends that you include thetransientTokenResponseOptions.includeCardPrefixfield in the capture context request and set its value tofalse. Doing so limits the exposure of payment data to only what is necessary for your processing needs.For more information about PCI DSS, seeFrequently Asked Questionson the PCI Security Standards Council site.
- Allowed Payment Types
- You can specify the type ofUnified Checkoutdigital payment methods that you want to accept in the capture context.
- Use theallowedPaymentTypesfield to define the payment type. TheClick to Pay Drop-In UIaccepts these payment types:
- CLICKTOPAY
- PANENTRY
IMPORTANTWhen you includeCLICKTOPAY,PANENTRYXXX.
IMPORTANT
When integrating with
Cybersource
APIs, Cybersource
recommends that you dynamically
parse the response for the fields that you are looking for. Additional fields may be added
in the future. You must ensure that your integration can handle new fields that are
returned in the response. While the underlying data structures will not change, you must
also ensure that your integration can handle changes to the order in which the data is
returned.
Cybersource
uses semantic versioning practices, which enables
you to retain backwards compatibility as new fields are introduced in minor version
updates.