{"title":"Native 3D Secure 2 authentication","category":"default","creationDate":1683717660,"content":"
\n \n <\/in-page-filtering>\n<\/div>\n
\n \n \n \n \n \n \n \n \n \n <\/div>\n","url":"https:\/\/docs.adyen.com\/pt\/online-payments\/3d-secure\/native-3ds2","articleFields":{"description":"Support 3D Secure 2 natively on your website or mobile app.","id":"39953298","type":"page","_expandable":{"operations":""},"status":"current","last_edit_on":"10-05-2023 13:22","feedback_component":true,"filters_component":true,"filters_config_folder":"3d-secure-native","dynamic_minitoc":true,"dynamic_minitoc_context":".in-page-filtering--content"},"algolia":[{"url":"https:\/\/docs.adyen.com\/pt\/online-payments\/3d-secure\/native-3ds2","title":"Native 3D Secure 2 authentication","content":"Web Drop-in\nProvide a better experience by performing 3D Secure 2 authentication natively on your website, without redirecting your shopper to an external website to authenticate.\nUse Drop-in to render the available cards in your payment form and securely collect card information, so sensitive data does not reach your server.\nDrop-in handles the 3D Secure 2 frictionless and challenge flows, including the data exchange between your front end and the issuer's Access Control Server (ACS).\nOther 3D Secure flows\nWith a native Web Drop-in 3D Secure 2 integration, you can also support:\n\nData-only flow\nThis page explains how to implement native 3D Secure 2 authentication with your existing Web Drop-in integration.\nRequirements\nBefore you begin, take into account the following requirements, limitations, and preparations.\n\n\n\nRequirement\nDescription\n\n\n\n\nIntegration type\nMake sure you have an Advanced flow Web Drop-in integration. If you use the Sessions flow, no additional configuration is needed to support 3D Secure 2.\n\n\nWebhooks\nSubscribe to Standard webhooks.\n\n\nLimitations\nA strict Content Security Policy (CSP) can prevent native 3D Secure 2 challenges from being loaded on your website, because loading the 3D Secure 2 interface requires adding more URLs to your CSP. Adyen does not maintain a list of all URLs. You can use the redirect flow if you do not want to adjust your CSP.\n\n\nSetup steps\nBefore you begin, add the card payment methods that you want to accept in your test Customer Area.\n\n\nHow it works\nWhen making a card payment with native 3D Secure 2 authentication:\n\nShow the available cards in your payment form.\nConfigure Drop-in to collect the cardholder name.\nProvide additional parameters when making a payment request.\nSubmit authentication result if you receive an action object in response to your \/payments or \/payments\/details request.\nHandle the redirect result if the payment was routed to the 3D Secure 2 redirect flow.\nShow the available cards in your payment form\n\nFor information about the supported countries\/regions and currencies for each card, refer to Payment methods.\n\nDrop-in uses the combination of countryCode and amount.currency from your \/paymentMethods request to show the available cards to your shopper.\nWhen the shopper is entering their card details, Drop-in tries to recognize the card brand. When successful, Drop-in renders the brand icon and the corresponding input field for the card security code (CVC, CVV, or CID).Collect additional information at checkout\nFor higher authentication rates, we strongly recommend that you collect the cardholder name, billing address, and email address for payments with 3D Secure authentication.\nConfigure cards with Drop-in\nWhen creating a configuration object for Drop-in, add optional configuration for cards in your paymentMethodsConfiguration object.\n\n\n\nField\nDescription\nDefault\n\n\n\n\nhasHolderName\nSet to\u00a0true\u00a0to show the input field for the card holder name.\nfalse\n\n\nholderNameRequired\nSet to\u00a0true\u00a0to make the card holder name a required field. To show the field, you additionally need to set hasHolderName to true.\nfalse\n\n\nbillingAddressRequired\nSet to true to collect the shopper's billing address.\nfalse\n\n\nchallengeWindowSize\nThe size of the challenge window displayed to the shopper in the challenge flow. Possible values: - '01': ['250px', '400px'] - '02': ['390px', '400px'] - '03': ['500px', '600px'] - '04': ['600px', '400px'] - '05': ['100%', '100%']\n'02': ['390px', '400px']\n\n\n\nYou can customize your shopper's experience further with optional configuration parameters and specific events.\n\n \n\nHandle Drop-in errors\nWhen an error occurs, the onError event returns an object which contains details about the error.\nFor errors that happen during the 3D Secure 2 authentication, you do not need to stop the payment flow because the shopper can continue.\nCollect shopper email in your payment form\nWe also recommend that you collect the shopper email in advance in your payment form. Deliver this parameter to your backend when making a payment, because it is required by the card schemes.Make a payment\nWhen the shopper selects to pay, Drop-in calls the onSubmit event, which contains a state.data.\n\n\nPass the state.data to your server.\n\n\nWhen you make a payment request, include the following additional 3D Secure 2 parameters.\n\nSee additional 3D Secure 2 parameters that we recommend to include in your request to increase authentication performance in our API reference.\n\n\n\n\nParameter name\nRequired\nDescription\n\n\n\n\n paymentMethod\n\nThe complete state.data.paymentMethod object from the onSubmit event. It includes the type and required details for a card payment method.\n\n\n paymentMethod.sdkData\n\nThe object that includes the following information collected by Drop-in:Information required for 3D Secure 2 authentication.The checkout attempt identifier to track the user's payment journey. This is required to use the Checkout dashboard that lets you analyze your checkout performance.\n\n\n paymentMethod.holderName\n\nUse case: required for Visa and JCB transactions. The cardholder's name.\n\n\n browserInfo\n\nThe shopper's browser information. All sub-fields of this object are required for channel: Web. This is the state.data.browserInfo object from the onSubmit event.\n\n\n authenticationData.threeDSRequestData.nativeThreeDS Checkout API v69 or later\n\nSet to preferred. Indicates if your payment page can handle native 3D Secure 2 authentication. <br For Checkout API v68 or earlier: use additionalData.allow3DS2 instead.\n\n\n channel\n\nThe platform where the transaction takes place. Set to Web.\n\n\n origin\n\nThe origin URL of the page where you are rendering Drop-in. To get the origin, open the browser console and call window.location.origin. When this field is not set, or set incorrectly, the 3D Secure 2 action can not be handled correctly. Format: Maximum characters: 80.Do not include subdirectories and a trailing slash. Example: if you render Drop-in on https:\/\/your-company.example.com\/checkout\/payment, set to https:\/\/your-company.example.com.\n\n\n returnUrl\n\nThe URL where the shopper is redirected back to after completing authentication, including the protocol http:\/\/ or https:\/\/. For example, https:\/\/your-company.example.com\/checkout\/. You can also include your own additional query parameters, for example, shopper ID or order reference number. This is to support cases where the payment is routed to the redirect flow.\n\n\n shopperEmail\n\nUse case: required for Visa and JCB transactions. The cardholder's email address. If you do not include this, you must send a phone number in the threeDS2RequestData object.\n\n\n shopperIP\n\nUse case: required for Visa and JCB transactions on the web. The shopper's IP address.\n\n\n telephoneNumber\n\nUse case: required for Visa and JCB transactions if you did not include the shopperEmail field. The shopper's phone number. To be more specific, you can use the mobilePhone, homePhone, and workPhone fields in the threeDS2RequestData object. Format: The phone number must include a plus sign (+) and a country code (1-3 digits), followed by the number (4-15 digits). Example: +4912345678901 If the value you provide does not follow the guidelines, we drop the value and do not submit it for authentication. \n\n\n\n Required for all transactions. Required for particular setups, or issuers and card schemes. Recommended for all transactions, but not required.\nBelow is an example \/payments request.\n\n\n\n\n\nIn the response, check if there is an action object. Your next steps depend on whether the response contains an action object, and on the action.type.\n\n\n\naction.type\nDescription\nNext steps\n\n\n\n\nNo action object\nThe transaction was either exempted or out-of-scope for 3D Secure 2 authentication.\nUse the resultCode to present the payment result to your shopper.\n\n\nthreeDS2\nThe payment qualifies for 3D Secure 2, and will go through the authentication flow.\n1. Pass the action object to your front end to perform the authentication flow. 2. Submit the challenge result.\n\n\nredirect\nThe payment is routed to the 3D Secure 2 redirect flow. \n1. Store action.paymentData on your server. 2. Pass the action object to your front end. 3. Handle the redirect result.\n\n\n\nThe following example shows a \/payments response with action.type: threeDS2.\n\n\n\n \nSubmit the authentication result\nDrop-in handles the action after it is returned within the onSubmit event and performs the required authentication flow. If the issuer requires shopper interaction, Drop-in presents the challenge screen.\n\n \n\nWhen the shopper completes the challenge, Drop-in calls the \n onAdditionalDetails\n event.\n\n\nGet the state.data from the onAdditionalDetails event, and pass it to your server.\n\n\nFrom your server, make a POST \/payments\/details request, specifying:\n\ndetails: The state.data.details from the onAdditionalDetails event.\n\n\n\n\nThe \/payments\/details response has a resultCode. You will need it to present the payment result.\n\n\nPass the resultCode you received in the \/payments\/details response to the actions.resolve() object. Depending on the result code, the onPaymentCompleted or onPaymentFailed event is triggered to complete the payment flow.\n\n\n\n\nPresent the payment result\nUse the\u00a0 resultCode from the \/payments or \/payments\/details response to present the payment result to your shopper. You will also receive the outcome of the payment asynchronously in a webhook.\n\nFor card payments, you can receive the following resultCode values:\n\n\n\nresultCode\nDescription\nAction to take\n\n\n\n\nAuthorised\nThe payment was successful.\nInform the shopper that the payment has been successful. If you are using manual capture, you also need to capture the payment.\n\n\nCancelled\nThe shopper cancelled the payment.\nAsk the shopper if they want to continue with the order, or ask them to select a different payment method.\n\n\nError\nThere was an error when the payment was being processed. For more information, check the \n refusalReason\n field.\nInform the shopper that there was an error processing their payment.\n\n\nRefused\nThe payment was refused. For more information, check the \n refusalReason\n field.\nAsk the shopper to try the payment again using a different payment method.\n\n\nTest and go live\nUse our test card numbers to test how your integration handles different 3D Secure authentication scenarios.\nWhen you are ready to go live, follow our go-live checklist.\nWhen using our live endpoints, make sure that all API requests you make for the same payment session use the same live endpoint region. Using different regions for \/payments and \/payments\/details requests may result in errors when authenticating with 3D Secure.\nLive environment values\n\n\n\nEndpoint region\nValue\n\n\n\n\nEurope (EU) live\nlive\n\n\nUnited States (US) live\nlive-us\n\n\nAustralia (AU) live\nlive-au\n\n\nAsia Pacific & Southeast (APSE) live\nlive-apse\n\n\nIndia (IN) live\nlive-in\n\n\nSee also\n\n\n Web Drop-in integration guide\n \n 3D Secure 2 API Reference\n \n 3D Secure authentication\n \n Webhooks\n \n","type":"page","locale":"pt","boost":17,"hierarchy":{"lvl0":"Home","lvl1":"Online payments","lvl2":"3D Secure 2 authentication","lvl3":"Native 3D Secure 2 authentication"},"hierarchy_url":{"lvl0":"https:\/\/docs.adyen.com\/pt","lvl1":"https:\/\/docs.adyen.com\/pt\/online-payments","lvl2":"https:\/\/docs.adyen.com\/pt\/online-payments\/3d-secure","lvl3":"\/pt\/online-payments\/3d-secure\/native-3ds2"},"levels":4,"category":"Online Payments","category_color":"green","tags":["Native","Secure","authentication"]},{"url":"https:\/\/docs.adyen.com\/pt\/online-payments\/3d-secure\/native-3ds2?platform=Web&integration=Drop-in","title":"Web Drop-in","content":"Web Drop-in\nProvide a better experience by performing 3D Secure 2 authentication natively on your website, without redirecting your shopper to an external website to authenticate.\nUse Drop-in to render the available cards in your payment form and securely collect card information, so sensitive data does not reach your server.\nDrop-in handles the 3D Secure 2 frictionless and challenge flows, including the data exchange between your front end and the issuer's Access Control Server (ACS).\nOther 3D Secure flows\nWith a native Web Drop-in 3D Secure 2 integration, you can also support:\n\nData-only flow\nThis page explains how to implement native 3D Secure 2 authentication with your existing Web Drop-in integration.\nRequirements\nBefore you begin, take into account the following requirements, limitations, and preparations.\n\n\n\nRequirement\nDescription\n\n\n\n\nIntegration type\nMake sure you have an Advanced flow Web Drop-in integration. If you use the Sessions flow, no additional configuration is needed to support 3D Secure 2.\n\n\nWebhooks\nSubscribe to Standard webhooks.\n\n\nLimitations\nA strict Content Security Policy (CSP) can prevent native 3D Secure 2 challenges from being loaded on your website, because loading the 3D Secure 2 interface requires adding more URLs to your CSP. Adyen does not maintain a list of all URLs. You can use the redirect flow if you do not want to adjust your CSP.\n\n\nSetup steps\nBefore you begin, add the card payment methods that you want to accept in your test Customer Area.\n\n\nHow it works\nWhen making a card payment with native 3D Secure 2 authentication:\n\nShow the available cards in your payment form.\nConfigure Drop-in to collect the cardholder name.\nProvide additional parameters when making a payment request.\nSubmit authentication result if you receive an action object in response to your \/payments or \/payments\/details request.\nHandle the redirect result if the payment was routed to the 3D Secure 2 redirect flow.\nShow the available cards in your payment form\n\nFor information about the supported countries\/regions and currencies for each card, refer to Payment methods.\n\nDrop-in uses the combination of countryCode and amount.currency from your \/paymentMethods request to show the available cards to your shopper.\nWhen the shopper is entering their card details, Drop-in tries to recognize the card brand. When successful, Drop-in renders the brand icon and the corresponding input field for the card security code (CVC, CVV, or CID).Collect additional information at checkout\nFor higher authentication rates, we strongly recommend that you collect the cardholder name, billing address, and email address for payments with 3D Secure authentication.\nConfigure cards with Drop-in\nWhen creating a configuration object for Drop-in, add optional configuration for cards in your paymentMethodsConfiguration object.\n\n\n\nField\nDescription\nDefault\n\n\n\n\nhasHolderName\nSet to\u00a0true\u00a0to show the input field for the card holder name.\nfalse\n\n\nholderNameRequired\nSet to\u00a0true\u00a0to make the card holder name a required field. To show the field, you additionally need to set hasHolderName to true.\nfalse\n\n\nbillingAddressRequired\nSet to true to collect the shopper's billing address.\nfalse\n\n\nchallengeWindowSize\nThe size of the challenge window displayed to the shopper in the challenge flow. Possible values: - '01': ['250px', '400px'] - '02': ['390px', '400px'] - '03': ['500px', '600px'] - '04': ['600px', '400px'] - '05': ['100%', '100%']\n'02': ['390px', '400px']\n\n\n\nYou can customize your shopper's experience further with optional configuration parameters and specific events.\n\n \n\nHandle Drop-in errors\nWhen an error occurs, the onError event returns an object which contains details about the error.\nFor errors that happen during the 3D Secure 2 authentication, you do not need to stop the payment flow because the shopper can continue.\nCollect shopper email in your payment form\nWe also recommend that you collect the shopper email in advance in your payment form. Deliver this parameter to your backend when making a payment, because it is required by the card schemes.Make a payment\nWhen the shopper selects to pay, Drop-in calls the onSubmit event, which contains a state.data.\n\n\nPass the state.data to your server.\n\n\nWhen you make a payment request, include the following additional 3D Secure 2 parameters.\n\nSee additional 3D Secure 2 parameters that we recommend to include in your request to increase authentication performance in our API reference.\n\n\n\n\nParameter name\nRequired\nDescription\n\n\n\n\n paymentMethod\n\nThe complete state.data.paymentMethod object from the onSubmit event. It includes the type and required details for a card payment method.\n\n\n paymentMethod.sdkData\n\nThe object that includes the following information collected by Drop-in:Information required for 3D Secure 2 authentication.The checkout attempt identifier to track the user's payment journey. This is required to use the Checkout dashboard that lets you analyze your checkout performance.\n\n\n paymentMethod.holderName\n\nUse case: required for Visa and JCB transactions. The cardholder's name.\n\n\n browserInfo\n\nThe shopper's browser information. All sub-fields of this object are required for channel: Web. This is the state.data.browserInfo object from the onSubmit event.\n\n\n authenticationData.threeDSRequestData.nativeThreeDS Checkout API v69 or later\n\nSet to preferred. Indicates if your payment page can handle native 3D Secure 2 authentication. <br For Checkout API v68 or earlier: use additionalData.allow3DS2 instead.\n\n\n channel\n\nThe platform where the transaction takes place. Set to Web.\n\n\n origin\n\nThe origin URL of the page where you are rendering Drop-in. To get the origin, open the browser console and call window.location.origin. When this field is not set, or set incorrectly, the 3D Secure 2 action can not be handled correctly. Format: Maximum characters: 80.Do not include subdirectories and a trailing slash. Example: if you render Drop-in on https:\/\/your-company.example.com\/checkout\/payment, set to https:\/\/your-company.example.com.\n\n\n returnUrl\n\nThe URL where the shopper is redirected back to after completing authentication, including the protocol http:\/\/ or https:\/\/. For example, https:\/\/your-company.example.com\/checkout\/. You can also include your own additional query parameters, for example, shopper ID or order reference number. This is to support cases where the payment is routed to the redirect flow.\n\n\n shopperEmail\n\nUse case: required for Visa and JCB transactions. The cardholder's email address. If you do not include this, you must send a phone number in the threeDS2RequestData object.\n\n\n shopperIP\n\nUse case: required for Visa and JCB transactions on the web. The shopper's IP address.\n\n\n telephoneNumber\n\nUse case: required for Visa and JCB transactions if you did not include the shopperEmail field. The shopper's phone number. To be more specific, you can use the mobilePhone, homePhone, and workPhone fields in the threeDS2RequestData object. Format: The phone number must include a plus sign (+) and a country code (1-3 digits), followed by the number (4-15 digits). Example: +4912345678901 If the value you provide does not follow the guidelines, we drop the value and do not submit it for authentication. \n\n\n\n Required for all transactions. Required for particular setups, or issuers and card schemes. Recommended for all transactions, but not required.\nBelow is an example \/payments request.\n\n\n\n\n\nIn the response, check if there is an action object. Your next steps depend on whether the response contains an action object, and on the action.type.\n\n\n\naction.type\nDescription\nNext steps\n\n\n\n\nNo action object\nThe transaction was either exempted or out-of-scope for 3D Secure 2 authentication.\nUse the resultCode to present the payment result to your shopper.\n\n\nthreeDS2\nThe payment qualifies for 3D Secure 2, and will go through the authentication flow.\n1. Pass the action object to your front end to perform the authentication flow. 2. Submit the challenge result.\n\n\nredirect\nThe payment is routed to the 3D Secure 2 redirect flow. \n1. Store action.paymentData on your server. 2. Pass the action object to your front end. 3. Handle the redirect result.\n\n\n\nThe following example shows a \/payments response with action.type: threeDS2.\n\n\n\n \nSubmit the authentication result\nDrop-in handles the action after it is returned within the onSubmit event and performs the required authentication flow. If the issuer requires shopper interaction, Drop-in presents the challenge screen.\n\n \n\nWhen the shopper completes the challenge, Drop-in calls the \n onAdditionalDetails\n event.\n\n\nGet the state.data from the onAdditionalDetails event, and pass it to your server.\n\n\nFrom your server, make a POST \/payments\/details request, specifying:\n\ndetails: The state.data.details from the onAdditionalDetails event.\n\n\n\n\nThe \/payments\/details response has a resultCode. You will need it to present the payment result.\n\n\nPass the resultCode you received in the \/payments\/details response to the actions.resolve() object. Depending on the result code, the onPaymentCompleted or onPaymentFailed event is triggered to complete the payment flow.\n\n\n\n\nPresent the payment result\nUse the\u00a0 resultCode from the \/payments or \/payments\/details response to present the payment result to your shopper. You will also receive the outcome of the payment asynchronously in a webhook.\n\nFor card payments, you can receive the following resultCode values:\n\n\n\nresultCode\nDescription\nAction to take\n\n\n\n\nAuthorised\nThe payment was successful.\nInform the shopper that the payment has been successful. If you are using manual capture, you also need to capture the payment.\n\n\nCancelled\nThe shopper cancelled the payment.\nAsk the shopper if they want to continue with the order, or ask them to select a different payment method.\n\n\nError\nThere was an error when the payment was being processed. For more information, check the \n refusalReason\n field.\nInform the shopper that there was an error processing their payment.\n\n\nRefused\nThe payment was refused. For more information, check the \n refusalReason\n field.\nAsk the shopper to try the payment again using a different payment method.\n\n\nTest and go live\nUse our test card numbers to test how your integration handles different 3D Secure authentication scenarios.\nWhen you are ready to go live, follow our go-live checklist.\nWhen using our live endpoints, make sure that all API requests you make for the same payment session use the same live endpoint region. Using different regions for \/payments and \/payments\/details requests may result in errors when authenticating with 3D Secure.\nLive environment values\n\n\n\nEndpoint region\nValue\n\n\n\n\nEurope (EU) live\nlive\n\n\nUnited States (US) live\nlive-us\n\n\nAustralia (AU) live\nlive-au\n\n\nAsia Pacific & Southeast (APSE) live\nlive-apse\n\n\nIndia (IN) live\nlive-in\n\n\nSee also\n\n\n Web Drop-in integration guide\n \n 3D Secure 2 API Reference\n \n 3D Secure authentication\n \n Webhooks\n \n","type":"page","locale":"pt","boost":17,"hierarchy":{"lvl0":"Home","lvl1":"Online payments","lvl2":"3D Secure 2 authentication","lvl3":"Native 3D Secure 2 authentication"},"hierarchy_url":{"lvl0":"https:\/\/docs.adyen.com\/pt","lvl1":"https:\/\/docs.adyen.com\/pt\/online-payments","lvl2":"https:\/\/docs.adyen.com\/pt\/online-payments\/3d-secure","lvl3":"\/pt\/online-payments\/3d-secure\/native-3ds2"},"levels":4,"category":"Online Payments","category_color":"green","tags":["Web","Drop-in"]},{"url":"https:\/\/docs.adyen.com\/pt\/online-payments\/3d-secure\/native-3ds2?platform=Web&integration=Components","title":"Web Components","content":"Web Components\nProvide a better experience by performing 3D Secure 2 authentication natively on your website, without redirecting your shopper to an external website to authenticate.\nUse our pre-built Component to render the available cards in your payment form and securely collect card information, so sensitive data does not reach your server.\nThe 3D Secure 2 Component handles the frictionless and challenge flows, including the data exchange between your front end and the issuer's Access Control Server (ACS).\nOther 3D Secure flows\nWith a native Web Components 3D Secure 2 integration, you can also support:\n\nData-only flow\nThis page explains how to implement native 3D Secure 2 authentication with your existing Web Components integration.\nRequirements\nBefore you begin, take into account the following requirements, limitations, and preparations.\n\n\n\nRequirement\nDescription\n\n\n\n\nIntegration type\nMake sure you have an Advanced flow Web Components integration with the Card Component. If you use the Sessions flow, no additional configuration is needed to support 3D Secure 2.\n\n\nWebhooks\nSubscribe to Standard webhooks.\n\n\nLimitations\nA strict Content Security Policy (CSP) can prevent native 3D Secure 2 challenges from being loaded on your website, because loading the 3D Secure 2 interface requires adding more URLs to your CSP. Adyen does not maintain a list of all URLs. You can use the redirect flow if you do not want to adjust your CSP.\n\n\nSetup steps\nBefore you begin, add the card payment methods that you want to accept in your test Customer Area.\n\n\nHow it works\nTo handle native 3D Secure 2 authentication:\n\nGet additional shopper details in your payment form.\nMake a payment request, including additional shopper details.\nHandle the 3D Secure 2 action to perform the authentication flow.\nSubmit the authentication result.\nShow the payment result.\nCollect additional shopper details in your payment form\nFor higher authentication rates, we strongly recommend that you collect the shopper's email address, cardholder name, billing address, and IP address for payments with 3D Secure authentication.\n\n\n \n \n \n \n\nMake a payment\n\n\nWhen you make a payment request, include the following additional 3D Secure 2 parameters.\n\nSee additional 3D Secure 2 parameters that we recommend to include in your request to increase authentication performance in our API reference.\n\n\n\n \n \n \n \n\n\nBelow is an example \/payments request for cases where you use your own payment form.\n\n\n\n\n\nIn the response, check if there is an action object. Your next steps depend on whether the response contains an action object, and on the action.type.\n\n\n\naction.type\nDescription\nNext steps\n\n\n\n\nNo action object\nThe transaction was either exempted or out-of-scope for 3D Secure 2 authentication.\nUse the resultCode to show the payment result to your shopper.\n\n\nthreeDS2\nThe payment qualifies for 3D Secure 2, and will go through the authentication flow.\n1. Pass the action object to your front end. 2. Use the Component to perform the authentication flow. 3. Submit the authentication result.\n\n\nredirect\nThe payment is routed to the 3D Secure 2 redirect flow. \n1. Pass the action object to your front end. 2. Use handleAction to handle the redirect. 3. Confirm the redirect result.\n\n\n\nThe following example shows a \/payments response with action.type: threeDS2.\n\n\n\n \nHandle the 3D Secure 2 action\nIf your integration uses the Card Component to collect the shopper's card details, also use it to handle the 3D Secure 2 action on the same page.\nIf you built your own UI for collecting the shopper's card details or want to render 3D Secure authentication on a different page than the payment, create a new 3D Secure 2 Component.\n\n\n \n \n \n \n\n\nHandle Component errors\nWhen an error occurs, the onError event returns an object which contains details about the error.\nFor errors that happen during the 3D Secure 2 authentication, you do not need to stop the payment flow because the shopper can continue.Submit the authentication result\n\n\nGet the state.data from the onAdditionalDetails event, and pass it your server.\n\n\nFrom your server, make a POST \/payments\/details request, specifying:\n\ndetails: The state.data.details from the onAdditionalDetails event.\n\n\n\n\nThe \/payments\/details response has a resultCode. You need it to show the payment result.\n\n\nPass the resultCode you received in the \/payments\/details to the actions.resolve() object in the onAdditionalDetails event.\n\n\nDepending on the resultCode, handle the payment flow with the onPaymentCompleted or onPaymentFailed event.\n\nPresent the payment result\nUse the\u00a0 resultCode from the \/payments or \/payments\/details response to present the payment result to your shopper. You will also receive the outcome of the payment asynchronously in a webhook.\n\nFor card payments, you can receive the following resultCode values:\n\n\n\nresultCode\nDescription\nAction to take\n\n\n\n\nAuthorised\nThe payment was successful.\nInform the shopper that the payment has been successful. If you are using manual capture, you also need to capture the payment.\n\n\nCancelled\nThe shopper cancelled the payment.\nAsk the shopper if they want to continue with the order, or ask them to select a different payment method.\n\n\nError\nThere was an error when the payment was being processed. For more information, check the \n refusalReason\n field.\nInform the shopper that there was an error processing their payment.\n\n\nRefused\nThe payment was refused. For more information, check the \n refusalReason\n field.\nAsk the shopper to try the payment again using a different payment method.\n\n\nTest and go live\nUse our test card numbers to test how your integration handles different 3D Secure authentication scenarios.\nWhen you are ready to go live, follow our go-live checklist.\nWhen using our live endpoints, make sure that all API requests you make for the same payment session use the same live endpoint region. Using different regions for \/payments and \/payments\/details requests may result in errors when authenticating with 3D Secure.\nLive environment values\n\n\n\nEndpoint region\nValue\n\n\n\n\nEurope (EU) live\nlive\n\n\nUnited States (US) live\nlive-us\n\n\nAustralia (AU) live\nlive-au\n\n\nAsia Pacific & Southeast (APSE) live\nlive-apse\n\n\nIndia (IN) live\nlive-in\n\n\nSee also\n\n\n Web Components integration guide\n \n 3D Secure 2 API Reference\n \n 3D Secure authentication\n \n Webhooks\n \n","type":"page","locale":"pt","boost":17,"hierarchy":{"lvl0":"Home","lvl1":"Online payments","lvl2":"3D Secure 2 authentication","lvl3":"Native 3D Secure 2 authentication"},"hierarchy_url":{"lvl0":"https:\/\/docs.adyen.com\/pt","lvl1":"https:\/\/docs.adyen.com\/pt\/online-payments","lvl2":"https:\/\/docs.adyen.com\/pt\/online-payments\/3d-secure","lvl3":"\/pt\/online-payments\/3d-secure\/native-3ds2"},"levels":4,"category":"Online Payments","category_color":"green","tags":["Web","Components"]},{"url":"https:\/\/docs.adyen.com\/pt\/online-payments\/3d-secure\/native-3ds2?platform=iOS&integration=Drop-in","title":"iOS Drop-in","content":"iOS Drop-in\nProvide a better experience by performing native 3D Secure 2 authentication in your iOS app.\nUse Drop-in to render the available cards in your payment form and securely collect card information, so sensitive data does not reach your server.\nDrop-in handles the 3D Secure 2 frictionless and challenge flows, including the data exchange between your front end and the issuer's Access Control Server (ACS).\nOther 3D Secure flows\nWith a native iOS Drop-in 3D Secure 2 integration, you can also support:\n\nData-only flow\nThis page explains how to implement native 3D Secure 2 authentication with your existing iOS Drop-in integration.\nRequirements\nBefore you begin, take into account the following requirements, limitations, and preparations.\n\n\n\nRequirement\nDescription\n\n\n\n\nIntegration type\nMake sure you have an Advanced flow iOS Drop-in integration. If you use the Sessions flow, no additional configuration is needed to support 3D Secure 2.\n\n\nWebhooks\nSubscribe to Standard webhooks.\n\n\nSetup steps\nBefore you begin: Add the card payment methods that you want to accept in your test Customer Area. Make sure that your back end can handle redirects for cases where the payment is routed to the Redirect 3D Secure 2 flow. \n\n\nHow it works\nOur iOS Drop-in renders the available cards in your payment form, and securely collects any sensitive card information, so it doesn't touch your server. Drop-in also handles the 3D Secure 2 device fingerprinting and challenge flows, including the data exchange between your front end and the issuer's Access Control Server (ACS).\nWhen making a card payment with native 3D Secure 2 authentication, you need to:\n\nConfigure Drop-in to collect the cardholder name.\nProvide additional parameters when making a payment request.\nSubmit the authentication result if you receive an action object in response to your \/payments or \/payments\/details request.\nIn some cases, the payment may be routed to the redirect flow, when this happens, handle the redirect.\nCollect additional information at checkout\nFor higher authentication rates, we strongly recommend that you collect the shopper cardholder name and billing address in advance in your payment form. Deliver these parameters to your backend when making a payment, because they are required by the card schemes.Show the available cards in your payment form\n\nFor information about the supported countries\/regions and currencies for each card, refer to Payment methods.\n\nTo show cards in your payment form:\n\n\nSpecify in your \/paymentMethods request a combination of countryCode and amount.currency. Drop-in uses this information to show the available cards to your shopper.\n\n\nWhen initializing the Drop-in, create a configuration object, and specify:\n\nconfiguration.card.showsHolderNameField: true. This shows the input field for the cardholder name.\n\n\n\nIf you want to set threeDSRequestorAppURL, create a configuration object and specify actionComponent.threeDS.requestorAppURL. Always use a universal link.\nlet configuration = DropInComponent.Configuration(apiContext: apiContext)\nconfiguration.card.showsHolderNameField = true \/\/ Shows the field for entering the holder name.\n\nconfiguration.actionComponent.threeDS.requestorAppURL = URL(string: \"YOUR_APP_URL\") \/\/ Optional, add a universal link here when you want to send threeDSRequestorAppURL.\n\n\nWhen the shopper is entering their card details, Drop-in tries to recognize the card brand. When successful, Drop-in renders the brand icon.Make a payment\nWhen the shopper proceeds to pay, Drop-in invokes the didSubmit method which contains data.paymentMethod. \n\n\nPass data.paymentMethod to your server.\nWhen you make a payment request, include the following additional 3D Secure 2 parameters.\n\nSee additional 3D Secure 2 parameters that we recommend to include in your request to increase authentication performance in our API reference.\n\n\n\n\nParameter name\nRequired\nDescription\n\n\n\n\n paymentMethod\n\nThe complete data.paymentMethod object from the didSubmit event from your client app. It includes the type and required details for a card payment method.\n\n\n paymentMethod.sdkData\n\nThe object that includes the following information collected by Drop-in:Information required for 3D Secure 2 authentication.The checkout attempt identifier to track the user's payment journey. This is required to use the Checkout dashboard that lets you analyze your checkout performance.\n\n\n paymentMethod.holderName\n\nUse case: required for Visa and JCB transactions. The cardholder's name.\n\n\n authenticationData.threeDSRequestData.nativeThreeDS Checkout API v69 or later\n\nSet to preferred. Indicates if your payment page can handle native 3D Secure 2 authentication. For Checkout API v68 or earlier: use additionalData.allow3DS2 instead.\n\n\n channel\n\nThe platform where the transaction takes place. Set to iOS.\n\n\n returnUrl\n\nUsed to redirect the shopper back to a webpage for redirect and other payment flows. If you want to redirect the shopper to your app, configure a threeDSRequestorAppURL.\n\n\n shopperEmail\n\nUse case: required for Visa and JCB transactions. The cardholder's email address. If you do not include this, you must send a phone number in the threeDS2RequestData object.\n\n\n shopperIP\n\nUse case: required for Visa and JCB transactions to support cases where the transaction is routed to the redirect flow. The shopper's IP address.\n\n\n telephoneNumber\n\nUse case: required for Visa and JCB transactions if you did not include the shopperEmail field. The shopper's phone number. To be more specific, you can use the mobilePhone, homePhone, and workPhone fields in the threeDS2RequestData object. Format: The phone number must include a plus sign (+) and a country code (1-3 digits), followed by the number (4-15 digits). Example: +4912345678901 If the value you provide does not follow the guidelines, we drop the value and do not submit it for authentication. \n\n\n browserInfo\n\nThe shopper's browser information. We recommend to include it in your requests to handle cases where authentication is routed to the redirect flow.\n\n\n\n Required for all transactions. Required for particular setups, or issuers and card schemes. Recommended for all transactions, but not required.\nGet the SDK version\nIn your payment request, you must include the current SDK version. To get the SDK version:\n\n\n\nBelow is an example \/payments request.\n\n\n\n\n\nIn the response, check if there is an action object.\n\n\n \n \n \n \n\nSubmit the authentication result\nIf the action object in the \/payments response contains threeDS2 (for Checkout API v67 and later), threeDS2Fingerprint, or threeDS2Challenge (for Checkout API v66 and earlier), submit the authentication result. Choose your API version:\n\n\n \n \n \n \n\nPresent the payment result\nUse the\u00a0 resultCode from the \/payments or \/payments\/details response to present the payment result to your shopper. You will also receive the outcome of the payment asynchronously in a webhook.\n\nFor card payments, you can receive the following resultCode values:\n\n\n\nresultCode\nDescription\nAction to take\n\n\n\n\nAuthorised\nThe payment was successful.\nInform the shopper that the payment has been successful. If you are using manual capture, you also need to capture the payment.\n\n\nCancelled\nThe shopper cancelled the payment.\nAsk the shopper if they want to continue with the order, or ask them to select a different payment method.\n\n\nError\nThere was an error when the payment was being processed. For more information, check the \n refusalReason\n field.\nInform the shopper that there was an error processing their payment.\n\n\nRefused\nThe payment was refused. For more information, check the \n refusalReason\n field.\nAsk the shopper to try the payment again using a different payment method.\n\n\nTest and go live\nUse our test card numbers to test how your integration handles different 3D Secure authentication scenarios.\nWhen you are ready to go live, follow our go-live checklist.\nWhen using our live endpoints, make sure that all API requests you make for the same payment session use the same live endpoint region. Using different regions for \/payments and \/payments\/details requests may result in errors when authenticating with 3D Secure.\nLive environment values\n\n\n\nEndpoint region\nValue\n\n\n\n\nEurope (EU) live\nliveEurope\n\n\nUnited States (US) live\nliveUnitedStates\n\n\nAustralia (AU) live\nliveAustralia\n\n\nAsia Pacific & Southeast (APSE) live\nliveApse\n\n\nIndia (IN) live\nliveIndia\n\n\nTroubleshooting\nIf native 3D Secure 2 is not triggered, check the following:\n\nchannel is set to iOS.\nYou have set 3D Secure 2 preferences to trigger native flow:\n\nFor Checkout API v69 or later: authenticationData.threeDSRequestData.nativeThreeDS is set to preferred.\nFor Checkout API v68 or earlier: additionalData.allow3DS2 is set to true .\n\nSee also\n\n\n iOS Drop-in integration guide\n \n 3D Secure 2 API Reference\n \n 3D Secure authentication\n \n Webhooks\n \n","type":"page","locale":"pt","boost":17,"hierarchy":{"lvl0":"Home","lvl1":"Online payments","lvl2":"3D Secure 2 authentication","lvl3":"Native 3D Secure 2 authentication"},"hierarchy_url":{"lvl0":"https:\/\/docs.adyen.com\/pt","lvl1":"https:\/\/docs.adyen.com\/pt\/online-payments","lvl2":"https:\/\/docs.adyen.com\/pt\/online-payments\/3d-secure","lvl3":"\/pt\/online-payments\/3d-secure\/native-3ds2"},"levels":4,"category":"Online Payments","category_color":"green","tags":["iOS","Drop-in"]},{"url":"https:\/\/docs.adyen.com\/pt\/online-payments\/3d-secure\/native-3ds2?platform=iOS&integration=Components","title":"iOS Components","content":"iOS Components\nProvide a better experience by performing native 3D Secure 2 authentication in your iOS app.\nUse our pre-built Component to render the available cards in your payment form and securely collect card information, so sensitive data does not reach your server.\nThe 3D Secure 2 Component handles the frictionless and challenge flows, including the data exchange between your front end and the issuer's Access Control Server (ACS).\nOther 3D Secure flows\nWith a native iOS Components 3D Secure 2 integration, you can also support:\n\nData-only flow\nThis page explains how to implement native 3D Secure 2 authentication with your existing iOS Components integration.\nRequirements\nBefore you begin, take into account the following requirements, limitations, and preparations.\n\n\n\nRequirement\nDescription\n\n\n\n\nIntegration type\nMake sure you have an Advanced flow iOS Components integration with the Card Component. If you use the Sessions flow, no additional configuration is needed to support 3D Secure 2.\n\n\nWebhooks\nSubscribe to Standard webhooks.\n\n\nSetup steps\nBefore you begin: Add the card payment methods that you want to accept in your test Customer Area. Make sure that your back end can handle redirects for cases where the payment is routed to the Redirect 3D Secure 2 flow. \n\n\nHow it works\nOur 3D Secure 2 Component handles the 3D Secure 2 device fingerprinting and challenge flows, including the data exchange between your front end and the issuer's Access Control Server (ACS).\nWhen adding native 3D Secure 2 authentication to your integration:\n\nCollect additional parameters in your payment form.\nProvide additional parameters when making a payment request.\nUse the Action Component to perform the authentication flow.\nSubmit authentication result, if you receive an action object in response to your API request.\nIn some cases, the payment may be routed to the redirect flow, when this happens, handle the redirect.\nCollect additional information at checkout\nFor higher authentication rates, we strongly recommend that you collect the cardholder name for payments with 3D Secure authentication.\nTo collect the cardholder name using our Card Component, specify the following when adding the Card Component:\n\nshowsHolderNameField: true\n\nlet configuration = CardComponent.Configuration(showsHolderNameField: true)\nlet component = CardComponent(paymentMethod: paymentMethod,\n apiContext: apiContext,\n configuration: configuration)\ncomponent.delegate = self\nself.cardComponent = component\npresent(component.viewController, animated: true)\nWe also recommend that you collect the shopper billing address in advance in your payment form. Deliver this parameter to your backend when making a payment as it is required by the card schemes.Make a payment\n\n\nWhen you make a payment request, include the following additional 3D Secure 2 parameters.\n\nSee additional 3D Secure 2 parameters that we recommend to include in your request to increase authentication performance in our API reference.\n\n\n\n\nParameter name\nRequired\nDescription\n\n\n\n\n paymentMethod\n\nThe complete data.paymentMethod object from the didSubmit event from your client app. It includes the type and required details for a card payment method.\n\n\n paymentMethod.sdkData\n\nThe object that includes the following information collected by the Component:Information required for 3D Secure 2 authentication.The checkout attempt identifier to track the user's payment journey. This is required to use the Checkout dashboard that lets you analyze your checkout performance.\n\n\n paymentMethod.holderName\n\nUse case: required for Visa and JCB transactions. The cardholder's name.\n\n\n authenticationData.threeDSRequestData.nativeThreeDS Checkout API v69 or later\n\nSet to preferred. Indicates if your payment page can handle native 3D Secure 2 authentication. <br For Checkout API v68 or earlier: use additionalData.allow3DS2 instead.\n\n\n channel\n\nThe platform where the transaction takes place. Set to iOS.\n\n\n returnUrl\n\nThe URL where the shopper will be redirected to after completing authentication. This is to support cases where the payment is routed to the redirect flow. If you want to redirect the shopper to your app, configure a threeDSRequestorAppURL.\n\n\n shopperEmail\n\nUse case: required for Visa and JCB transactions. The cardholder's email address. If you do not include this, you must send the telephoneNumber, or a phone number in the threeDS2RequestData object.\n\n\n shopperIP\n\nUse case: required for Visa and JCB transactions to support cases where the transaction is routed to the redirect flow. The shopper's IP address.\n\n\n telephoneNumber\n\nUse case: required for Visa and JCB transactions if you did not include the shopperEmail field. The shopper's phone number. To be more specific, you can use the mobilePhone, homePhone, and workPhone fields in the threeDS2RequestData object. Format: The phone number must include a plus sign (+) and a country code (1-3 digits), followed by the number (4-15 digits). Example: +4912345678901 If the value you provide does not follow the guidelines, we drop the value and do not submit it for authentication. \n\n\n browserInfo\n\nThe shopper's browser information. We recommend to include it in your requests to handle cases where authentication is routed to the redirect flow.\n\n\n\n Required for all transactions. Required for particular setups, or issuers and card schemes. Recommended for all transactions, but not required.\nGet the SDK version\nIn your payment request, you must include the current SDK version. To get the SDK version:\n\n\n\nBelow is an example \/payments request.\n\n\n\n\n\nIn the response, check if there is an action object.\n\n\n \n \n \n \n\nUse the Action Component\nUse the \n AdyenActionComponent\n to perform the 3D Secure 2 authentication flows, and receive the information that you need to submit in your next API request.\n\n\nCreate and persist an instance of AdyenActionComponent.\nTo set a threeDSRequestorAppURL, create a configuration object and specify actionComponent.threeDS.requestorAppURL. Always use a universal link.\nlet component = AdyenActionComponent(apiContext: apiContext, configuration: configuration)\ncomponent.delegate = self\ncomponent.presentationDelegate = presentationDelegate\nself.adyenActionComponent = component\ncomponent.configuration.threeDS.requestorAppURL = URL(string: \"https:\/\/{yourapp.com}\/adyen3ds2\")\n\n\n Pass the action object from the \/payments or \/payments\/details response.\nlet action = try JSONDecoder().decode(Action.self, from: actionData)\nadyenActionComponent.handle(action)\n\nSubmit the authentication result\nAfter completing authentication, the Component invokes the didSubmit ( \/payments) or the didProvide ( \/payments\/details) method, which contain data.details.\n\n\n \n \n \n \n\n\nHandling 3D Secure redirect\nIf you get action: redirect, the Component must handle the redirect. Implement the following:\n\nYou must inform the AdyenActionComponent when the shopper returns to your app. To do this, implement the following in your UIApplicationDelegate:\n\nfunc application(_ app: UIApplication, open url: URL, options: [UIApplicationOpenURLOptionsKey: Any] = [:]) -> Bool {\n RedirectComponent.applicationDidOpen(from: url)\n return true\n}\n\n\nAfter AdyenActionComponent completes the authentication, it invokes the didProvide method from the ActionComponentDelegate. Get the contents of data and pass this to your server.\nfunc didProvide(_ data: ActionComponentData, from component: ActionComponent)\nIn case an error occurs on the app, the Component invokes the didFail method from the ActionComponentDelegate. Dismiss the Component's view controller and display an error message.\nfunc didFail(with error: Error, from component: ActionComponent)\n\nPresent the payment result\nUse the\u00a0 resultCode from the \/payments or \/payments\/details response to present the payment result to your shopper. You will also receive the outcome of the payment asynchronously in a webhook.\n\nFor card payments, you can receive the following resultCode values:\n\n\n\nresultCode\nDescription\nAction to take\n\n\n\n\nAuthorised\nThe payment was successful.\nInform the shopper that the payment has been successful. If you are using manual capture, you also need to capture the payment.\n\n\nCancelled\nThe shopper cancelled the payment.\nAsk the shopper if they want to continue with the order, or ask them to select a different payment method.\n\n\nError\nThere was an error when the payment was being processed. For more information, check the \n refusalReason\n field.\nInform the shopper that there was an error processing their payment.\n\n\nRefused\nThe payment was refused. For more information, check the \n refusalReason\n field.\nAsk the shopper to try the payment again using a different payment method.\n\n\nCustomize the UI for 3D Secure 2\nThe Component inherits your app's theme to ensure the UI of the challenge flow fits your app's look and feel. For more UI customizations, use the customization options provided in the \n appearanceConfiguration\n property.\nFor more information on iOS Components classes, refer to our Reference documentation.Test and go live\nUse our test card numbers to test how your integration handles different 3D Secure authentication scenarios.\nWhen you are ready to go live, follow our go-live checklist.\nWhen using our live endpoints, make sure that all API requests you make for the same payment session use the same live endpoint region. Using different regions for \/payments and \/payments\/details requests may result in errors when authenticating with 3D Secure.\nLive environment values\n\n\n\nEndpoint region\nValue\n\n\n\n\nEurope (EU) live\nliveEurope\n\n\nUnited States (US) live\nliveUnitedStates\n\n\nAustralia (AU) live\nliveAustralia\n\n\nAsia Pacific & Southeast (APSE) live\nliveApse\n\n\nIndia (IN) live\nliveIndia\n\n\nTroubleshooting\nIf native 3D Secure 2 is not triggered, check the following:\n\nchannel is set to iOS.\nYou have set 3D Secure 2 preferences to trigger native flow:\n\nFor Checkout API v69 or later: authenticationData.threeDSRequestData.nativeThreeDS is set to preferred.\nFor Checkout API v68 or earlier: additionalData.allow3DS2 is set to true .\n\nSee also\n\n\n iOS Components integration guide\n \n 3D Secure 2 API Reference\n \n Webhooks\n \n Payment methods\n \n","type":"page","locale":"pt","boost":17,"hierarchy":{"lvl0":"Home","lvl1":"Online payments","lvl2":"3D Secure 2 authentication","lvl3":"Native 3D Secure 2 authentication"},"hierarchy_url":{"lvl0":"https:\/\/docs.adyen.com\/pt","lvl1":"https:\/\/docs.adyen.com\/pt\/online-payments","lvl2":"https:\/\/docs.adyen.com\/pt\/online-payments\/3d-secure","lvl3":"\/pt\/online-payments\/3d-secure\/native-3ds2"},"levels":4,"category":"Online Payments","category_color":"green","tags":["iOS","Components"]},{"url":"https:\/\/docs.adyen.com\/pt\/online-payments\/3d-secure\/native-3ds2?platform=Android&integration=Drop-in","title":"Android Drop-in","content":"Android Drop-in\nProvide a better experience by performing native 3D Secure 2 authentication in your Android app.\nUse Drop-in to render the available cards in your payment form and securely collect card information, so sensitive data does not reach your server.\nDrop-in handles the 3D Secure 2 frictionless and challenge flows, including the data exchange between your front end and the issuer's Access Control Server (ACS).\nOther 3D Secure flows\nWith a native Android Drop-in 3D Secure 2 integration, you can also support:\n\nData-only flow\nThis page explains how to implement native 3D Secure 2 authentication with your existing Android Drop-in integration.\nRequirements\nBefore you begin, take into account the following requirements, limitations, and preparations.\n\n\n\nRequirement\nDescription\n\n\n\n\nIntegration type\nMake sure you have an Advanced flow Android Drop-in integration. If you use the Sessions flow, no additional configuration is needed to support 3D Secure 2.\n\n\nWebhooks\nSubscribe to Standard webhooks.\n\n\nSetup steps\nBefore you begin: Add the card payment methods that you want to accept in your test Customer Area. Make sure that your back end can handle redirects for cases where the payment is routed to the Redirect 3D Secure 2 flow. \n\n\nHow it works\nFor a Drop-in integration, you must implement the following parts:\n\nYour payment server: sends the API requests to get available payment methods, make a payment, and send additional payment details. \n\nYour client app: shows the Drop-in UI where the shopper makes the payment. Drop-in uses the data from the API responses to handle the payment flow and additional actions on your client app. \nYour webhook server: receives webhooks that include the outcome of each payment.\n\nThe parts of your integration work together to complete the payment flow:\n\n \n\n\nFrom your server, submit a request to get a list of payment methods available to the shopper.\nConfigure and launch Drop-in to collect the shopper's details.\nFrom your server, make a payment request with data that you receive from Drop-in.\nHandle additional client-side actions, if required.\nFrom your server, send additional payment details with data you receive from Drop-in, if required.\nGet the payment outcome to inform the shopper and update your order management system.\n\nIf you are integrating these parts separately, you can start at the corresponding part of this integration guide:\n\n\n Payment server\n Go to the integration steps for your server.\n Client app\n Go to the integration steps for your client app.\n Webhook server\n Go to the integration steps for your webhook server.\nCollect additional information at checkout\nFor higher authentication rates, we strongly recommend that you collect the shopper's billing address and email address. Send these parameters to your server when making a payment, because they are required by the card schemes.Optional configuration\nWhen you configure the Drop-in, you can include the following functions:\n\n\n\nConfiguration function\nDescription\nParameter\n\n\n\n\nsetThreeDSRequestorAppURL\nStrongly recommended to improve conversion rates. Set this to an Android App link to call your app after an out-of-band (OOB) authentication occurs. When set, your app must also handle this Android App link. We do not recommend to use custom links because they can be defined and used by other apps. This causes errors if two apps on the same device have the same custom link.\nthreeDSRequestorAppURL: String.Default: null.\n\n\nsetUiCustomization\nCustomization for the 3D Secure 2 authentication UI.\nA \n UiCustomization\n object.\n\n\n\nFor example:\n\n \n\nAfter configuring Drop-in, continue to launch and show Drop-in and make the payment request.Make a payment\n\n\nWhen you make a payment request, include the following additional 3D Secure 2 parameters.\n\nSee additional 3D Secure 2 parameters that we recommend to include in your request to increase authentication performance in our API reference.\n\n\n\n\nParameter name\nRequired\nDescription\n\n\n\n\n paymentMethod\n\nThe complete paymentComponentData.paymentMethod object from your client app. It includes the type and required details for a card payment method.\n\n\n paymentMethod.sdkData\n\nThe object that includes the following information collected by Drop-in:Information required for 3D Secure 2 authentication.The checkout attempt identifier to track the user's payment journey. This is required to use the Checkout dashboard that lets you analyze your checkout performance.\n\n\n paymentMethod.holderName\n\nUse case: required for Visa and JCB transactions. The cardholder's name.\n\n\n authenticationData.threeDSRequestData.nativeThreeDS Checkout API v69 or later\n\nSet to preferred. Indicates if your payment page can handle native 3D Secure 2 authentication. For Checkout API v68 or earlier: use additionalData.allow3DS2 instead.\n\n\n channel\n\nSet to Android. The platform where the transaction takes place.\n\n\n returnUrl\n\nUsed to redirect the shopper back to a webpage for redirect and other payment flows. We strongly recommend to redirect the shopper to your app by configuring a threeDSRequestorAppURL, because this improves conversion.\n\n\n shopperEmail\n\nUse case: required for Visa and JCB transactions. The cardholder's email address. If you do not include this, you must send the telephoneNumber, or a phone number in the threeDS2RequestData object.\n\n\n shopperIP\n\nUse case: required for Visa and JCB transactions to support cases where the transaction is routed to the redirect flow. The shopper's IP address.\n\n\n telephoneNumber\n\nUse case: required for Visa and JCB transactions if you did not include the shopperEmail field. The shopper's phone number. To be more specific, you can use the mobilePhone, homePhone, and workPhone fields in the threeDS2RequestData object. Format: The phone number must include a plus sign (+) and a country code (1-3 digits), followed by the number (4-15 digits). Example: +4912345678901 If the value you provide does not follow the guidelines, we drop the value and do not submit it for authentication. \n\n\n browserInfo\n\nThe shopper's browser information. We recommend to include it in your requests to handle cases where authentication is routed to the redirect flow.\n\n\n\n Required for all transactions. Required for particular setups, or issuers and card schemes. Recommended for all transactions, but not required.\nBelow is an example \/payments request.\n\n\n\n\n\nIn the response, check if there is an action object.\n\n\n \n \n \n \n\nSubmit additional 3D Secure 2 authentication details\nWhen you send additional details, send the 3D Secure 2 authentication data from your server:\n\n\nDrop-in calls the onAdditionalDetails method in your DropInService class passing, the actionComponentJson object. Pass the object to your backend server.\n\n\nFrom your server, make a POST \/payments\/details request, including actionComponentJson object:\n\n\n\n\n\nPass the \/payments\/details response from your server to your client-side app.\n\n\nContinue and complete your payment flow.Present the payment result\nUse the\u00a0 resultCode from the \/payments or \/payments\/details response to present the payment result to your shopper. You will also receive the outcome of the payment asynchronously in a webhook.\n\nFor card payments, you can receive the following resultCode values:\n\n\n\nresultCode\nDescription\nAction to take\n\n\n\n\nAuthorised\nThe payment was successful.\nInform the shopper that the payment has been successful. If you are using manual capture, you also need to capture the payment.\n\n\nCancelled\nThe shopper cancelled the payment.\nAsk the shopper if they want to continue with the order, or ask them to select a different payment method.\n\n\nError\nThere was an error when the payment was being processed. For more information, check the \n refusalReason\n field.\nInform the shopper that there was an error processing their payment.\n\n\nRefused\nThe payment was refused. For more information, check the \n refusalReason\n field.\nAsk the shopper to try the payment again using a different payment method.\n\n\nHandle your Android App Link\nIf you have configured the setThreeDSRequestorAppURL when you configured Drop-in, you have to handle this Android App link.\n\n\nAdd the following to your AndroidManifest.xml, specifying your Android App Link as your android:host:\n\n\n\n\n\nVerify the App Link.\n\nTest and go live\nUse our test card numbers to test how your integration handles different 3D Secure authentication scenarios.\nWhen you are ready to go live, follow our go-live checklist.\nWhen using our live endpoints, make sure that all API requests you make for the same payment session use the same live endpoint region. Using different regions for \/payments and \/payments\/details requests may result in errors when authenticating with 3D Secure.\nLive environment values\n\n\n\nEndpoint region\nValue\n\n\n\n\nEurope (EU) live\nEUROPE\n\n\nUnited States (US) live\nUNITED_STATES\n\n\nAustralia (AU) live\nAUSTRALIA\n\n\nAsia Pacific & Southeast (APSE) live\nAPSE\n\n\nIndia (IN) live\nINDIA\n\n\nTroubleshooting\nIf native 3D Secure 2 is not triggered, check the following:\n\nchannel is set to Android.\nYou have set 3D Secure 2 preferences to trigger native flow:\n\nFor Checkout API v69 or later: authenticationData.threeDSRequestData.nativeThreeDS is set to preferred.\nFor Checkout API v68 or earlier: additionalData.allow3DS2 is set to true .\n\nSee also\n\n\n Android Drop-in integration guide\n \n 3D Secure 2 API Reference\n \n Webhooks\n \n Payment methods\n \n","type":"page","locale":"pt","boost":17,"hierarchy":{"lvl0":"Home","lvl1":"Online payments","lvl2":"3D Secure 2 authentication","lvl3":"Native 3D Secure 2 authentication"},"hierarchy_url":{"lvl0":"https:\/\/docs.adyen.com\/pt","lvl1":"https:\/\/docs.adyen.com\/pt\/online-payments","lvl2":"https:\/\/docs.adyen.com\/pt\/online-payments\/3d-secure","lvl3":"\/pt\/online-payments\/3d-secure\/native-3ds2"},"levels":4,"category":"Online Payments","category_color":"green","tags":["Android","Drop-in"]},{"url":"https:\/\/docs.adyen.com\/pt\/online-payments\/3d-secure\/native-3ds2?platform=Android&integration=Components","title":"Android Components","content":"Android Components\nProvide a better experience by performing native 3D Secure 2 authentication in your Android app.\nUse our pre-built Component to render the available cards in your payment form and securely collect card information, so sensitive data does not reach your server.\nThe 3D Secure 2 Component handles the frictionless and challenge flows, including the data exchange between your front end and the issuer's Access Control Server (ACS).\nOther 3D Secure flows\nWith a native Android Components 3D Secure 2 integration, you can also support:\n\nData-only flow\nThis page explains how to implement native 3D Secure 2 authentication with your existing Android Components integration.\nRequirements\nBefore you begin, take into account the following requirements, limitations, and preparations.\n\n\n\nRequirement\nDescription\n\n\n\n\nIntegration type\nMake sure you have an Advanced flow Android Components integration with the Card Component. If you use the Sessions flow, no additional configuration is needed to support 3D Secure 2.\n\n\nWebhooks\nSubscribe to Standard webhooks.\n\n\nSetup steps\nBefore you begin: Add the card payment methods that you want to accept in your test Customer Area. Make sure that your back end can handle redirects for cases where the payment is routed to the Redirect 3D Secure 2 flow. \n\n\nHow it works\nFor a Components integration, you must implement the following parts:\n\nYour payment server: sends the API requests to get available payment methods, make a payment, and send additional payment details. \n\nYour client app: shows the the Component UI where the shopper makes the payment. The Component uses the data from the API responses to handle the payment flow and additional actions on your client app. \nYour webhook server: receives webhooks that include the outcome of each payment.\n\nThe parts of your integration work together to complete the payment flow:\n\n\nFrom your server, submit a request to get a list of payment methods available to the shopper.\nConfigure and launch the Component to collect the shopper's details.\nFrom your server, make a payment request with data that you receive from the Component.\nHandle additional client-side actions, if required.\nFrom your server, send additional payment details that you receive from the Component, if required.\nGet the payment outcome to inform the shopper and update your order management system.\n\nIf you are integrating these parts separately, you can start at the corresponding part of this integration guide:\n\n\n Payment server\n Go to the integration steps for your server.\n Client app\n Go to the integration steps for your client app.\n Webhook server\n Go to the integration steps for your webhook server.\nCollect additional information at checkout\nFor higher authentication rates, we strongly recommend that you collect the cardholder name in your payment form.\nTo collect the cardholder name using our Card Component, specify the following when adding the Card Component:\n\nsetHolderNameRequired(true)\n\nval checkoutConfiguration = CheckoutConfiguration(\n environment = environment,\n clientKey = clientKey,\n) {\n card {\n setHolderNameRequired(true)\n }\n}\nWe also recommend that you collect the shopper's billing address and email address in advance in your payment form. Deliver these parameters to your backend when making a payment as it is required by the card schemes.Make a payment\n\n\nWhen you make a payment request, include the following additional 3D Secure 2 parameters.\n\nSee additional 3D Secure 2 parameters that we recommend to include in your request to increase authentication performance in our API reference.\n\n\n\n\nParameter name\nRequired\nDescription\n\n\n\n\n paymentMethod\n\nThe complete paymentComponentState.data.paymentMethod object from your client app. It includes the type and required details for a card payment method.\n\n\n paymentMethod.sdkData\n\nThe object that includes the following information collected by the Component:Information required for 3D Secure 2 authentication.The checkout attempt identifier to track the user's payment journey. This is required to use the Checkout dashboard that lets you analyze your checkout performance.\n\n\n paymentMethod.holderName\n\nUse case: required for Visa and JCB transactions. The cardholder's name.\n\n\n authenticationData.threeDSRequestData.nativeThreeDS Checkout API v69 or later\n\nSet to preferred. Indicates if your payment page can handle native 3D Secure 2 authentication. For Checkout API v68 or earlier: use additionalData.allow3DS2 instead.\n\n\n channel\n\nThe platform where the transaction takes place. Set to Android.\n\n\n returnUrl\n\nUsed to redirect the shopper back to a webpage for redirect and other payment flows. We strongly recommend to redirect the shopper to your app by configuring a threeDSRequestorAppURL, because this improves conversion.\n\n\n shopperEmail\n\nUse case: required for Visa and JCB transactions. The cardholder's email address. If you do not include this, you must send the telephoneNumber, or a phone number in the threeDS2RequestData object.\n\n\n shopperIP\n\nUse case required for Visa and JCB transactions to support cases where the transaction is routed to the redirect flow. The shopper's IP address.\n\n\n telephoneNumber\n\nUse case: required for Visa and JCB transactions if you did not include the shopperEmail field. The shopper's phone number. To be more specific, you can use the mobilePhone, homePhone, and workPhone fields in the threeDS2RequestData object. Format: The phone number must include a plus sign (+) and a country code (1-3 digits), followed by the number (4-15 digits). Example: +4912345678901 If the value you provide does not follow the guidelines, we drop the value and do not submit it for authentication. \n\n\n browserInfo\n\nThe shopper's browser information. We recommend to include it in your requests to handle cases where authentication is routed to the redirect flow.\n\n\n\n Required for all transactions. Required for particular setups, or issuers and card schemes. Recommended for all transactions, but not required.\nBelow is an example \/payments request.\n\n\n\n\n\nIn the response, check if there is an action object.\n\n\n \n \n \n \n\nUse the Action Component\n\n\nWhen you import the library, import the Action Component:\n\n\n\n\n\nWhen you configure the Component, you can include the following functions:\n\n\n\nConfiguration function\nDescription\nParameter\n\n\n\n\nsetThreeDSRequestorAppURL\nStrongly recommended to improve conversion rates. Set this to an Android App link to call your app after an out-of-band (OOB) authentication occurs. When set, your app must also handle this Android App link. We do not recommend to use custom links because they can be defined and used by other apps. This causes errors if two apps on the same device have the same custom link.\nthreeDSRequestorAppURL: String.Default: null.\n\n\nsetUiCustomization\nCustomization for the 3D Secure 2 authentication UI.\nA \n UiCustomization\n object.\n\n\n\nFor example:\n\n\n\n\n\nAdd AdyenComponentView to your layout .xml file. For example:\n\n\n\n\n\nCreate the Action Component by calling PROVIDER.get from your Component class:\n\n\n\n\n\nAttach your Component to your activity or fragment. For example to attach your Component to your view with the identifier adyenComponentView:\n\n\n\n\n\nWhen you get a response with an action, call handleAction:\n\n\n\n\n\nThe Component calls the onAdditionalDetails method in your ComponentCallback class and passes the actionComponentJson object. Pass the object to your backend server.\n\n\n\n\n\nPass the \/payments\/details response from your backend server to your frontend app.\nContinue and complete your payment flow.\n\nHandle a redirect\nIn some cases, your shopper is routed to perform 3D Secure redirect authentication instead. When this happens, handle the redirect:\n\n\nAdd an IntentFilter to the Activity that will handle the returnUrl specified in your \/payments request.\n\n\n\nThe android:host value is your package name at build time.\n\n\nGet the result of the redirect from the Activity. Pass the intent back to the Component. Depending on your activity's launchMode, you can get this intent in either onCreate or onNewIntent.\n\n\n\n\n\nThe onAdditionalDetails callback gets triggered.\nContinue and complete your payment flow.Present the payment result\nUse the\u00a0 resultCode from the \/payments or \/payments\/details response to present the payment result to your shopper. You will also receive the outcome of the payment asynchronously in a webhook.\n\nFor card payments, you can receive the following resultCode values:\n\n\n\nresultCode\nDescription\nAction to take\n\n\n\n\nAuthorised\nThe payment was successful.\nInform the shopper that the payment has been successful. If you are using manual capture, you also need to capture the payment.\n\n\nCancelled\nThe shopper cancelled the payment.\nAsk the shopper if they want to continue with the order, or ask them to select a different payment method.\n\n\nError\nThere was an error when the payment was being processed. For more information, check the \n refusalReason\n field.\nInform the shopper that there was an error processing their payment.\n\n\nRefused\nThe payment was refused. For more information, check the \n refusalReason\n field.\nAsk the shopper to try the payment again using a different payment method.\n\n\nHandle your Android App Link\nIf you have configured the setThreeDSRequestorAppURL when you configured the Action Component, you have to handle this Android App link.\n\n\nAdd the following to your AndroidManifest.xml, specifying your Android App Link as your android:host:\n\n\n\n\n\nVerify the App Link.\n\nCustomize the UI for 3D Secure 2\nThe 3D Secure 2 Component inherits your app's theme to ensure the UI of the challenge flow fits your app's look and feel. You can override the default theme to inherit from one of AppCompat's theme variants. To do this, add the following XML snippet to your styles.xml file.\n<style name=\"ThreeDS2Theme\" parent=\"Theme.MaterialComponents.Light.Bridge\">\n <!-- Customize the SDK theme here. -->\n <item name=\"colorPrimary\">@color\/colorPrimary<\/item>\n <item name=\"colorPrimaryDark\">@color\/colorPrimaryDark<\/item>\n <item name=\"colorAccent\">@color\/colorAccent<\/item>\n<\/style>Test and go live\nUse our test card numbers to test how your integration handles different 3D Secure authentication scenarios.\nWhen you are ready to go live, follow our go-live checklist.\nWhen using our live endpoints, make sure that all API requests you make for the same payment session use the same live endpoint region. Using different regions for \/payments and \/payments\/details requests may result in errors when authenticating with 3D Secure.\nLive environment values\n\n\n\nEndpoint region\nValue\n\n\n\n\nEurope (EU) live\nEUROPE\n\n\nUnited States (US) live\nUNITED_STATES\n\n\nAustralia (AU) live\nAUSTRALIA\n\n\nAsia Pacific & Southeast (APSE) live\nAPSE\n\n\nIndia (IN) live\nINDIA\n\n\nTroubleshooting\nIf native 3D Secure 2 is not triggered, check the following:\n\nchannel is set to Android.\nYou have set 3D Secure 2 preferences to trigger native flow:\n\nFor Checkout API v69 or later: authenticationData.threeDSRequestData.nativeThreeDS is set to preferred.\nFor Checkout API v68 or earlier: additionalData.allow3DS2 is set to true .\n\nSee also\n\n\n Android Components integration guide\n \n 3D Secure 2 API Reference\n \n Webhooks\n \n Payment methods\n \n","type":"page","locale":"pt","boost":17,"hierarchy":{"lvl0":"Home","lvl1":"Online payments","lvl2":"3D Secure 2 authentication","lvl3":"Native 3D Secure 2 authentication"},"hierarchy_url":{"lvl0":"https:\/\/docs.adyen.com\/pt","lvl1":"https:\/\/docs.adyen.com\/pt\/online-payments","lvl2":"https:\/\/docs.adyen.com\/pt\/online-payments\/3d-secure","lvl3":"\/pt\/online-payments\/3d-secure\/native-3ds2"},"levels":4,"category":"Online Payments","category_color":"green","tags":["Android","Components"]},{"url":"https:\/\/docs.adyen.com\/pt\/online-payments\/3d-secure\/native-3ds2?platform=Flutter&integration=Drop-in","title":"Flutter Drop-in","content":"Flutter Drop-in\nProvide a better experience by performing native 3D Secure 2 authentication in your mobile app.\nUse Drop-in to render the available cards in your payment form and securely collect card information, so sensitive data does not reach your server.\nA Flutter integration using the Advanced flow does not require any additional configuration to support 3D Secure 2. On this page, we walk you through the flow for 3D Secure 2 authentication.\nOther 3D Secure flows\nWith a native Flutter Drop-in 3D Secure 2 integration, you can also support:\n\nData-only flow\nRequirements\nBefore you begin, take into account the following requirements, preparations, and limitations.\n\n\n\nRequirement\nDescription\n\n\n\n\nIntegration type\nMake sure you have an Advanced flow Flutter Drop-in integration using Checkout API v71 or later. If you use the Sessions flow, no additional configuration is needed to support 3D Secure 2.\n\n\nWebhooks\nSubscribe to the Standard webhooks.\n\n\nSetup steps\nBefore you begin: Add the card payment methods that you want to accept in your test Customer Area.Integrate with the Flutter Drop-in.\n\n\nHow it works\nTo support 3D Secure 2 authentication with your integration:\n\nAdd recommended configuration to collect additional information at checkout to include it when authenticating a payment.\nMake a payment request, including additional shopper details.\nIn the payment response you receive, parse the JSON object included in the action object.\nThe Flutter SDK handles the action.\nForward the action result in your \/payments\/details request.\nShow the payment result.\nAdd configurations for 3D Secure authentication\nFor higher authentication rates, we strongly recommend that you collect the cardholder name, the shopper billing address and email address in advance in your payment form. For some schemes, it is required to include this information when making a payment.\nTo collect additional shopper information using our Flutter card component, include the following in your Drop-in configuration:\n\n\n\nParameter\nDescription\n\n\n\n\nholderNameRequired\nSet to true to require the cardholder name.\n\n\naddressMode\nSpecify which address fields are required. Possible values: -full: require the full address. -postalCode: require the postal code. -none: address not required.\n\n\n\n\n\n\n \n\nAdd the Requestor App Url\nOptionally, you can add the ThreeDS2Configuration object in your DropInConfiguration. Currently, this object supports configuring an app URL to call your app after an out-of-band (OOB) authentication occurs. We strongly recommend this to improve conversion rates.\n\n\n\nConfiguration field\nDescription\n\n\n\n\nrequestorAppUrl\nSet the URL for your app to redirect shoppers back to your app after authentication. For iOS, set this to the universal link for your app. For Android, set this to an Android App Link. When set, you must also handle this app link.\n\n\n\nHandle your Android App Link\nTo handle Android App Links:\n\n\nAdd the following to your AndroidManifest.xml, specifying your Android App Link as your android:host:\n\n\n\n\n\nVerify the App Link.\n\nMake a payment\nWhen the shopper selects the Pay button, your Drop-in integration invokes the \n onSubmit\n method.\n\n\nIn your POST \/payments request, include the following additional 3D Secure 2 parameters.\n\nSee additional 3D Secure 2 parameters that we recommend to include in your request to increase authentication performance in our API reference.\n\n\n\n\nParameter name\nRequired\nDescription\n\n\n\n\n paymentMethod\n\nThe complete paymentComponentData.paymentMethod object from your client app. It includes the payment method details and other required information.\n\n\n paymentMethod.sdkData\n\nThe object that includes the following information collected by Drop-in:Information required for 3D Secure 2 authentication.The checkout attempt identifier to track the user's payment journey. This is required to use the Checkout dashboard that lets you analyze your checkout performance.\n\n\n paymentMethod.holderName\n\nUse case: required for Visa and JCB transactions. The cardholder's name.\n\n\n authenticationData.threeDSRequestData.nativeThreeDS\n\nIndicates if your payment page can handle native 3D Secure 2 authentication. Set to preferred.\n\n\n channel\n\nThe platform where the transaction takes place. Set to Android.\n\n\n returnUrl\n\nThe URL where the shopper should return to after a redirection. iOS: Use the custom URL scheme for your app. You also need to: Add the return URL handler to your AppDelegate in your native iOS layer.Configure the custom URL scheme in your Info.plist file. iOS example: com.mydomain.adyencheckout:\/\/ Android: Use the combination of: adyencheckout:\/\/ schemeYour package name Use the AdyenCheckout.instance.getReturnUrl() method to get the value, or hardcode the string. Android example: adyencheckout:\/\/com.adyen.adyen_checkout_example Format: Maximum 1024 characters. The URL must not include personally identifiable information (PII), for example name or email address. \n\n\n shopperEmail\n\nUse case: required for Visa and JCB transactions. The cardholder's email address. If you do not include this, you must send the telephoneNumber, or a phone number in the threeDS2RequestData object.\n\n\n shopperIP\n\nUse case: required for Visa and JCB transactions to support cases where the transaction is routed to the redirect flow. The shopper's IP address.\n\n\n telephoneNumber\n\nUse case: required for Visa and JCB transactions if you did not include the shopperEmail field. The shopper's phone number. To be more specific, you can use the mobilePhone, homePhone, and workPhone fields in the threeDS2RequestData object. Format: The phone number must include a plus sign (+) and a country code (1-3 digits), followed by the number (4-15 digits). Example: +4912345678901 If the value you provide does not follow the guidelines, we drop the value and do not submit it for authentication. \n\n\n browserInfo\n\nThe shopper's browser information. We recommend to include it in your requests to handle cases where authentication is routed to the redirect flow.\n\n\n\n Required for all transactions. Required for particular setups, or issuers and card schemes. Recommended for all transactions, but not required.\n\n\n\n\n\nAfter you make the payment request, you receive an API response that includes an action object. This object informs you of the additional action that is required to complete the payment.\n\n\nYour integration maps the response to the Action \n PaymentEvent\n object.\n\nForward the action result\nDrop-in automatically handles the authentication action. After the shopper completes authentication, Drop-in invokes the onAdditionalDetails, which provides the 3D Secure 2 authentication result.\n\n\nIn your \/payments\/details request, include the data object from the onAdditionalDetails callback.\n\n\n\n\n\nThe \n resultCode\n informs you of the payment result.\n\nShow the payment result\nUse the\u00a0 resultCode from the \/payments or \/payments\/details response to present the payment result to your shopper. You will also receive the outcome of the payment asynchronously in a webhook.\n\nFor card payments, you can receive the following resultCode values:\n\n\n\nresultCode\nDescription\nAction to take\n\n\n\n\nAuthorised\nThe payment was successful.\nInform the shopper that the payment has been successful. If you are using manual capture, you also need to capture the payment.\n\n\nCancelled\nThe shopper cancelled the payment.\nAsk the shopper if they want to continue with the order, or ask them to select a different payment method.\n\n\nError\nThere was an error when the payment was being processed. For more information, check the \n refusalReason\n field.\nInform the shopper that there was an error processing their payment.\n\n\nRefused\nThe payment was refused. For more information, check the \n refusalReason\n field.\nAsk the shopper to try the payment again using a different payment method.\n\n\nTest and go live\nBefore going live, use our list of test cards and other payment methods to\u00a0test your integration. We recommend testing each payment method that you intend to offer to your shoppers.\nYou can check the status of a test payment in your\u00a0Customer Area, under Transactions >\u00a0Payments.\nTo debug or troubleshoot test payments, you can also use API logs in your test environment.\nWhen you are ready to go live, you need to:\n\nApply for a live account. Review the process to start accepting payments on Get started with Adyen.\nAssess your PCI DSS compliance by submitting the Self-Assessment Questionnaire-A.\nConfigure your live account.\u00a0\nSubmit a request to add payment methods in your live Customer Area .\nSwitch from test to our live endpoints.\n\nMake sure that all API requests you make for the same payment session use the same live endpoint region. Using different regions for \/payments and \/payments\/details requests may result in errors, for example, when authenticating with 3D Secure 2.\n\n\nLoad Drop-in from one of our live environments and set the environment to match your live endpoints:\n\n\n\nEndpoint region\nValue\n\n\n\n\nEurope (EU) live\neurope\n\n\nUnited States (US) live\nunitedStates\n\n\nAustralia (AU) live\naustralia\n\n\nAsia Pacific & Southeast (APSE) live\napse\n\n\nIndia (IN) live\nindia\n\n\n\n\nSee also\n\n\n Flutter Advanced flow integration guide\n \n 3D Secure 2 API Reference\n \n Webhooks\n \n Cards\n \n","type":"page","locale":"pt","boost":17,"hierarchy":{"lvl0":"Home","lvl1":"Online payments","lvl2":"3D Secure 2 authentication","lvl3":"Native 3D Secure 2 authentication"},"hierarchy_url":{"lvl0":"https:\/\/docs.adyen.com\/pt","lvl1":"https:\/\/docs.adyen.com\/pt\/online-payments","lvl2":"https:\/\/docs.adyen.com\/pt\/online-payments\/3d-secure","lvl3":"\/pt\/online-payments\/3d-secure\/native-3ds2"},"levels":4,"category":"Online Payments","category_color":"green","tags":["Flutter","Drop-in"]},{"url":"https:\/\/docs.adyen.com\/pt\/online-payments\/3d-secure\/native-3ds2?platform=Flutter&integration=Components","title":"Flutter Components","content":"Flutter Components\nProvide a better experience by performing native 3D Secure 2 authentication in your mobile app.\nUse our pre-built Component to render the available cards in your payment form and securely collect card information, so sensitive data does not reach your server.\nA Flutter integration using the Advanced flow does not require any additional configuration to support 3D Secure 2. On this page, we walk you through the flow for 3D Secure 2 authentication.\nOther 3D Secure flows\nWith a native Flutter Components 3D Secure 2 integration, you can also support:\n\nData-only flow\nRequirements\nBefore you begin, take into account the following requirements, preparations, and limitations.\n\n\n\nRequirement\nDescription\n\n\n\n\nIntegration type\nMake sure you have an Advanced flow Flutter Components integration using Checkout API v71 or later.\n\n\nWebhooks\nSubscribe to the Standard webhooks.\n\n\nSetup steps\nBefore you begin: Add the card payment methods that you want to accept in your test Customer Area.Integrate with the Flutter Card Component.\n\n\nHow it works\nTo support 3D Secure 2 authentication with your integration:\n\nAdd recommended configuration to collect additional information at checkout to include it when authenticating a payment.\nMake a payment request, including additional shopper details.\nIn the payment response you receive, parse the JSON object included in the action object.\nThe Flutter SDK handles the action.\nForward the action result in your \/payments\/details request.\nShow the payment result.\nConfigure the Card Component for 3D Secure authentication\nFor higher authentication rates, we strongly recommend that you collect the cardholder name, the shopper billing address and email address in advance in your payment form. For some schemes, it is required to include this information when making a payment.\nTo collect additional shopper information using our Flutter card component, include the following in your Component configuration:\n\n\n\nParameter\nDescription\n\n\n\n\nholderNameRequired\nSet to true to require the cardholder name.\n\n\naddressMode\nSpecify which address fields are required. Possible values: -full: require the full address. -postalCode: require the postal code. -none: address not required.\n\n\nrequestorAppUrl\nThe URL to call your app after an out-of-band (OOB) authentication occurs. We strongly recommend this to improve conversion rates. For iOS, set this to the universal link for your app. For Android, set this to an Android App Link. When set, you must also handle this app link.\n\n\n\n\n \n\nHandle your Android App Link\nTo handle Android App Links:\n\n\nAdd the following to your AndroidManifest.xml, specifying your Android App Link as your android:host:\n\n\n\n\n\nVerify the App Link.\n\nMake a payment\n\n\nWhen you make a payment request, include the following additional 3D Secure 2 parameters.\n\nSee additional 3D Secure 2 parameters that we recommend to include in your request to increase authentication performance in our API reference.\n\n\n\n\nParameter name\nRequired\nDescription\n\n\n\n\n paymentMethod\n\nThe complete paymentComponentData.paymentMethod object from your client app. It includes the payment method details and other required information.\n\n\n paymentMethod.sdkData\n\nThe object that includes the following information collected by the Component:Information required for 3D Secure 2 authentication.The checkout attempt identifier to track the user's payment journey. This is required to use the Checkout dashboard that lets you analyze your checkout performance.\n\n\n paymentMethod.holderName\n\nUse case: required for Visa and JCB transactions. The cardholder's name.\n\n\n authenticationData.threeDSRequestData.nativeThreeDS\n\nIndicates if your payment page can handle native 3D Secure 2 authentication. Set to preferred.\n\n\n channel\n\nThe platform where the transaction takes place. Set to Android.\n\n\n returnUrl\n\nThe URL where the shopper should return to after a redirection. iOS: Use the custom URL scheme for your app. You also need to: Add the return URL handler to your AppDelegate in your native iOS layer.Configure the custom URL scheme in your Info.plist file. iOS example: com.mydomain.adyencheckout:\/\/ Android: Use the combination of: adyencheckout:\/\/ schemeYour package nameA path. You must add an intent filter to your Manifest.xml file with this path. This is required for Components. Android example: adyencheckout:\/\/com.adyen.adyen_checkout_example\/adyenPayment Format: Maximum 1024 characters. The URL must not include personally identifiable information (PII), for example name or email address. \n\n\n shopperEmail\n\nUse case: required for Visa and JCB transactions. The cardholder's email address. If you do not include this, you must send the telephoneNumber, or a phone number in the threeDS2RequestData object.\n\n\n shopperIP\n\nUse case: required for Visa and JCB transactions to support cases where the transaction is routed to the redirect flow. The shopper's IP address.\n\n\n telephoneNumber\n\nUse case: required for Visa and JCB transactions if you did not include the shopperEmail field. The shopper's phone number. To be more specific, you can use the mobilePhone, homePhone, and workPhone fields in the threeDS2RequestData object. Format: The phone number must include a plus sign (+) and a country code (1-3 digits), followed by the number (4-15 digits). Example: +4912345678901 If the value you provide does not follow the guidelines, we drop the value and do not submit it for authentication. \n\n\n browserInfo\n\nThe shopper's browser information. We recommend to include it in your requests to handle cases where authentication is routed to the redirect flow.\n\n\n\n Required for all transactions. Required for particular setups, or issuers and card schemes. Recommended for all transactions, but not required.\n\n\n\n\n\nAfter you make the payment request, you receive an API response that includes an action object. This object informs you of the additional action that is required to complete the payment.\n\n\nYour integration maps the response to the Action \n PaymentEvent\n object.\n\nForward the action result\nComponent automatically handles the authentication action. After the shopper completes authentication, Component invokes the onAdditionalDetails, which provides the 3D Secure 2 authentication result.\n\n\nIn your \/payments\/details request, include the data object from the onAdditionalDetails callback.\n\n\n\n\n\nThe resultCode informs you of the payment result.\n\nShow the payment result\nUse the\u00a0 resultCode from the \/payments or \/payments\/details response to present the payment result to your shopper. You will also receive the outcome of the payment asynchronously in a webhook.\n\nFor card payments, you can receive the following resultCode values:\n\n\n\nresultCode\nDescription\nAction to take\n\n\n\n\nAuthorised\nThe payment was successful.\nInform the shopper that the payment has been successful. If you are using manual capture, you also need to capture the payment.\n\n\nCancelled\nThe shopper cancelled the payment.\nAsk the shopper if they want to continue with the order, or ask them to select a different payment method.\n\n\nError\nThere was an error when the payment was being processed. For more information, check the refusalReason field.\nInform the shopper that there was an error processing their payment.\n\n\nRefused\nThe payment was refused. For more information, check the refusalReason field.\nAsk the shopper to try the payment again using a different payment method.\n\n\nTest and go live\nUse our test card numbers to test how your integration handles different 3D Secure authentication scenarios.\nWhen you are ready to go live, follow our go-live checklist.\nWhen using our live endpoints, make sure that all API requests you make for the same payment session use the same live endpoint region. Using different regions for \/payments and \/payments\/details requests may result in errors when authenticating with 3D Secure.\nLive environment values\n\n\n\nEndpoint region\nValue\n\n\n\n\nEurope (EU) live\neurope\n\n\nUnited States (US) live\nunitedStates\n\n\nAustralia (AU) live\naustralia\n\n\nAsia Pacific & Southeast (APSE) live\napse\n\n\nIndia (IN) live\nindia\n\n\nSee also\n\n\n Flutter Advanced flow integration guide\n \n 3D Secure 2 API Reference\n \n Webhooks\n \n Cards\n \n","type":"page","locale":"pt","boost":17,"hierarchy":{"lvl0":"Home","lvl1":"Online payments","lvl2":"3D Secure 2 authentication","lvl3":"Native 3D Secure 2 authentication"},"hierarchy_url":{"lvl0":"https:\/\/docs.adyen.com\/pt","lvl1":"https:\/\/docs.adyen.com\/pt\/online-payments","lvl2":"https:\/\/docs.adyen.com\/pt\/online-payments\/3d-secure","lvl3":"\/pt\/online-payments\/3d-secure\/native-3ds2"},"levels":4,"category":"Online Payments","category_color":"green","tags":["Flutter","Components"]},{"url":"https:\/\/docs.adyen.com\/pt\/online-payments\/3d-secure\/native-3ds2?platform=React Native&integration=Drop-in","title":"React Native Drop-in","content":"React Native Drop-in\nProvide a better experience by performing native 3D Secure 2 authentication in your mobile app.\nUse Drop-in to render the available cards in your payment form and securely collect card information, so sensitive data does not reach your server.\nA React Native integration using the Advanced flow does not require any additional configuration to support 3D Secure 2. On this page, we walk you through the flow and optional configurations for 3D Secure 2 authentication.\nOther 3D Secure flows\nWith a native 3D Secure 2 integration, you can also support:\n\nData-only flow\nRequirements\nBefore you begin, take into account the following requirements, preparations, and limitations.\n\n\n\nRequirement\nDescription\n\n\n\n\nIntegration type\nMake sure you have an Advanced flow React Native Drop-in integration using Checkout API v71 or later. If you use the Sessions flow, no additional configuration is needed to support 3D Secure 2.\n\n\nWebhooks\nSubscribe to the Standard webhooks.\n\n\nSetup steps\nBefore you begin: Add the card payment methods that you want to accept in your test Customer Area.Integrate with the React Native Drop-in.\n\n\nHow it works\nTo support 3D Secure 2 authentication with your integration:\n\nAdd recommended configuration to collect additional information at checkout to include it when authenticating a payment.\nMake a payment request, including additional shopper details.\nIn the payment response you receive, parse the JSON object included in the action object.\nThe React Native SDK handles the action.\nForward the action result in your \/payments\/details request.\nShow the payment result.\nConfigure the Card Component for 3D Secure authentication\nFor higher authentication rates, we strongly recommend that you collect the cardholder name, the shopper billing address and email address in advance in your payment form. For some schemes, it is required to include this information when making a payment.\nTo collect additional shopper information using our React Native card component, include the following card and 3D Secure 2 specific parameters in your AdyenCheckout configuration object.\n\n\n\nParameter\nDescription\n\n\n\n\nholderNameRequired\nSet to true to require the cardholder name.\n\n\naddressVisibility\nSpecify which address fields are shown in the payment form. Possible values: -full: show all address fields. -postalCode: show only the postal code. -none: do not show address fields. - lookup: suggest addresses to the shopper when they enter data into address input.\n\n\nrequestorAppUrl\nThe URL to call your app after an out-of-band (OOB) authentication occurs to override the default returnUrl. We strongly recommend this to improve conversion rates. For iOS, set this to the universal link for your app. For Android, set this to an Android App Link. When set, you must also handle this app link.\n\n\n\n\n \n\nHandle your Android App Link\nTo handle Android App Links:\n\n\nAdd the following to your AndroidManifest.xml, specifying your Android App Link as your android:host:\n\n\n\n\n\nVerify the App Link.\n\nMake a payment\nWhen the shopper selects the Pay button, your Drop-in integration invokes the \n onSubmit\n method.\n\n\nIn your POST \/payments request, include the following additional 3D Secure 2 parameters.\n\nSee additional 3D Secure 2 parameters that we recommend to include in your request to increase authentication performance in our API reference.\n\n\n\n\nParameter name\nRequired\nDescription\n\n\n\n\n paymentMethod\n\nThe complete paymentComponentData.paymentMethod object from your client app that includes the payment method details and other required information.\n\n\n paymentMethod.sdkData\n\nThe object that includes the following information collected by the Component:Information required for 3D Secure 2 authentication.The checkout attempt identifier to track the user's payment journey. This is required to use the Checkout dashboard that lets you analyze your checkout performance.\n\n\n paymentMethod.holderName\n\nUse case: required for Visa and JCB transactions. The cardholder's name.\n\n\n authenticationData.threeDSRequestData.nativeThreeDS\n\nIndicates if your payment page can handle native 3D Secure 2 authentication. Set to preferred.\n\n\n channel\n\nSet a global channel constant to dynamically identify the channel using React Native's Platform.select utility.\n\n\n returnUrl\n\nSet a returnUrl constant to redirect the shopper to your app after a redirection. For more information on setting a custom URL scheme for your app, read the Apple Developer documentation. Format: Maximum 1024 characters. If the URL to return to includes non-ASCII characters, like spaces or special letters, URL encode the value. The URL must not include personally identifiable information (PII), for example name or email address. \n\n\n shopperEmail\n\nUse case: required for Visa and JCB transactions. The cardholder's email address. If you do not include this, you must send the telephoneNumber, or a phone number in the threeDS2RequestData object.\n\n\n shopperIP\n\nUse case: required for Visa and JCB transactions to support cases where the transaction is routed to the redirect flow. The shopper's IP address.\n\n\n telephoneNumber\n\nUse case: required for Visa and JCB transactions if you did not include the shopperEmail field. The shopper's phone number. To be more specific, you can use the mobilePhone, homePhone, and workPhone fields in the threeDS2RequestData object. Format: The phone number must include a plus sign (+) and a country code (1-3 digits), followed by the number (4-15 digits). Example: +4912345678901 If the value you provide does not follow the guidelines, we drop the value and do not submit it for authentication. \n\n\n browserInfo\n\nThe shopper's browser information. We recommend to include it in your requests to handle cases where authentication is routed to the redirect flow.\n\n\n\n Required for all transactions. Required for particular setups, or issuers and card schemes. Recommended for all transactions, but not required.\n\n\n\n\n\nCheck the action object in the API response you receive. If the transaction requires 3D Secure 2 authentication, you receive action.type: threeDS2.\n\n\nYour integration handles the 3D Secure 2 authentication action.\n\n\nSetting a channel constant\nUse the React Native Platform.select utility to dynamically identify iOS and Android environments.\n\n \n\nSetting a returnUrl constant\nUse the React Native Platform.select utility to dynamically set a returnUrl for iOS and Android environments.\n\n \nForward the action result\nDrop-in handles the authentication action. After the shopper completes authentication, Drop-in invokes the onAdditionalDetails, which provides the 3D Secure 2 authentication result. Your integration passes the data object to your server.\n\n\nIn your \/payments\/details request, include the data object from the onAdditionalDetails callback.\n\n\n\n\n\nThe \n resultCode\n in the API response informs you of the payment result. Pass the response from your server to your client app.\n\nShow the payment result\nUse the\u00a0 resultCode from the \/payments or \/payments\/details response to present the payment result to your shopper. You will also receive the outcome of the payment asynchronously in a webhook.\n\nFor card payments, you can receive the following resultCode values:\n\n\n\nresultCode\nDescription\nAction to take\n\n\n\n\nAuthorised\nThe payment was successful.\nInform the shopper that the payment has been successful. If you are using manual capture, you also need to capture the payment.\n\n\nCancelled\nThe shopper cancelled the payment.\nAsk the shopper if they want to continue with the order, or ask them to select a different payment method.\n\n\nError\nThere was an error when the payment was being processed. For more information, check the \n refusalReason\n field.\nInform the shopper that there was an error processing their payment.\n\n\nRefused\nThe payment was refused. For more information, check the \n refusalReason\n field.\nAsk the shopper to try the payment again using a different payment method.\n\n\nTest and go live\nUse our test card numbers to test how your integration handles different 3D Secure authentication scenarios.\nWhen you are ready to go live, follow our go-live checklist.\nWhen using our live endpoints, make sure that all API requests you make for the same payment session use the same live endpoint region. Using different regions for \/payments and \/payments\/details requests may result in errors when authenticating with 3D Secure.\nLive environment values\n\n\n\nEndpoint region\nValue\n\n\n\n\nEurope (EU) live\nlive-eu\n\n\nUnited States (US) live\nlive-us\n\n\nAustralia (AU) live\nlive-au\n\n\nAsia Pacific & Southeast (APSE) live\nlive-apse\n\n\nIndia (IN) live\nlive-in\n\n\nSee also\n\n\n React Native Advanced flow integration guide\n \n 3D Secure 2 API Reference\n \n Webhooks\n \n Cards\n \n","type":"page","locale":"pt","boost":17,"hierarchy":{"lvl0":"Home","lvl1":"Online payments","lvl2":"3D Secure 2 authentication","lvl3":"Native 3D Secure 2 authentication"},"hierarchy_url":{"lvl0":"https:\/\/docs.adyen.com\/pt","lvl1":"https:\/\/docs.adyen.com\/pt\/online-payments","lvl2":"https:\/\/docs.adyen.com\/pt\/online-payments\/3d-secure","lvl3":"\/pt\/online-payments\/3d-secure\/native-3ds2"},"levels":4,"category":"Online Payments","category_color":"green","tags":["React Native","Drop-in"]}],"articleFiles":{"android.svg":"\"\"","ios.svg":"\"\"","web.svg":"\"\""}}