\n <\/in-page-filtering>\n<\/div>\n\n <\/div>\n","url":"https:\/\/docs.adyen.com\/pt\/payment-methods\/payto\/web-drop-in","articleFields":{"description":"Add PayTo to your Drop-in integration.","never_cache_twig":true,"parameters":{"tx_variant":"payto","component_class_name":"PayTo","integration":"Drop-in","integration2":"Drop-in-web","pm_directory":"payto"},"filters_component":true,"filters_config_folder":"payment-methods\/payto\/web\/dropin-web"},"algolia":[{"url":"https:\/\/docs.adyen.com\/pt\/payment-methods\/payto\/web-drop-in","title":"Web Drop-in","content":"Requirements\n\n\n\nRequirement\nDescription\n\n\n\n\nIntegration type\nMake sure that you have an existing Sessions flow Web Drop-in integration.\n\n\n\nCheckout API\nMake sure that you use Checkout API v70 or later.\n \n\n\nSetup steps\nBefore you begin, add PayTo in your Customer Area.\n\n\n\nAdd additional parameters to your \/sessions request\nWhen you create a payment session, add the following parameters:\nThe additional parameters that you include depends on the type of PayTo payment.\n\nOne time payment\nSubscription setup and first payment\n\n\nSubsequent subscription payments can only be performed with:\n\n\n Advanced flow \nAPI Only\n\n\nOne-time payment\nTo offer one-time payments, add the following additional parameters.\n\n\n\nParameter\nRequired\nDescription\n\n\n\n\n shopperName.firstName\n\nThe shopper's first name.\n\n\n shopperName.lastName\n\nThe shopper's last name.\n\n\n shopperStatement\n\nThe text that shows up on the shopper's statement.\n\n\n lineItems.quantity\n\nFrom 0 to 9999.\n\n\n lineItems.sku\n\nUp to 200 characters.\n\n\n lineItems.description\n\nUsed to display the payment statement description to the shopper.Up to 280 characters. If multiple items, the item descriptions will be appended with a \",\" separator.\n\n\n lineItems.amountIncludingTax\n\nFrom 1 to 100000000.\n\n\n lineItems.itemCategory\n\nUp to 200 characters.\n\n\n\n reference\n\nThe reference to uniquely identify a payment. We recommend using a unique value per payment; however, it is not a requirement.Important: For PayTo, the maximum length is 35 characters.\n\n\n\n\n \n\nThe response includes the following.\n\n\n\nParameter\nDescription\n\n\n\n\nmandate.frequency\nadhoc\n\n\nmandate.endsAt\nThe end date. By default, it is set to one day after the payment request is sent.\n\n\nmandate.amount\nThe amount of the payment. It is the same as the amount sent in the payment request.\n\n\nmandate.amountRule\nexact\n\n\nmandate.count\n1\n\n\nmandate.remarks\nThe text that appears on the shopper's statement. By default, the text is One time payment.\n\n\n\n\n \n\nSubscription setup and first payment\nTo set up a subscription agreement with specific conditions and accept the first payment from the shopper, add the following parameters.\n\n\n\nParameter\nRequired\nDescription\n\n\n\n\n shopperName.firstName\n\nThe shopper's first name.\n\n\n shopperName.lastName\n\nThe shopper's last name.\n\n\n storePaymentMethod\n\nSet to true to store payment details for subscription payments.\n\n\n recurringProcessingModel\n\nSubscription\n\n\n shopperInteraction\n\nEcommerce\n\n\n mandate.frequency\n\nThe frequency with which a shopper should be charged.Possible values: adhoc, daily, weekly, biWeekly, monthly, quarterly, halfYearly, yearly.adhoc: Suitable for Card On File and Unscheduled Card On File recurring processing models.daily, weekly, biWeekly, monthly, quarterly, halfYearly, yearly: Suitable for Subscription recurring processing model.\n\n\n mandate.endsAt\n\nEnd date of the billing plan, in YYYY-MM-DD format.\n\n\n mandate.amount\n\nThe billing amount (in minor units) of the recurring transactions. 1 to 1000000000.\n\n\n mandate.amountRule\n\nThe limitation rule of the billing amount.Possible values:max: The transaction amount can not exceed the amount.exact: The transaction amount should be the same as the amount.\n\n\n mandate.remarks\n\nThe agreement description shown to the shopper up to 140 characters.\n\n\n mandate.count\n\nThe number of transactions that can be performed within the given frequency.Conditions:If the frequency is different than adhoc the count has to be provided and should be >= 1If frequency is adhoc the count can be omitted or will represent the total number of payments that can be done.\n\n\n mandate.startsAt\n\nStart date of the billing plan, in YYYY-MM-DD format. By default, the transaction date.\n\n\n lineItems.quantity \n 1\n\n\nFrom 0 to 9999.\n\n\n lineItems.sku \n 1\n\n\nUp to 200 characters. Note that this field is only available from v70 onwards.\n\n\n lineItems.description \n 1\n\n\nUsed to display the payment statement description to the shopper.Up to 280 characters. If multiple items, the item descriptions will be appended with a \",\" separator.\n\n\n lineItems.amountIncludingTax \n 1\n\n\nFrom 1 to 100000000.\n\n\n lineItems.itemCategory \n 1\n\n\nUp to 200 characters.\n\n\n reference\n\nThe reference to uniquely identify a payment. We recommend using a unique value per payment; however, it is not a requirement.Important: For PayTo, the maximum length is 35 characters.\n\n\n\n\n1 The lineItems information are consolidated and provided to PayTo as the payment description, and can be shown in the shopper's banking app (depending on the bank's capabilities).\n\nThe following example shows a request to create a session that offers the shopper a subscription agreement with a first payment of 30 AUD and a weekly payment of up to 90 AUD.\n\n\n\nParameter\nExample value\nDescription\n\n\n\n\namount.value\n3000\nAfter the shopper accepts the subscription agreement, they make a first, immediate payment of 30 AUD.\n\n\nmandate.frequency\nweekly\nA payment must be made weekly.\n\n\nmandate.amount\n9000\nThe amount of the weekly payment.\n\n\nmandate.amountRule\nmax\nThe maximum amount of the weekly payment is the mandate.amount of 90 AUD.\n\n\nmandate.count\n1\nThe shopper can make only one payment each week.\n\n\nmandate.endsAt\n2025-12-31\nThe subscription agreement ends on December 31, 2025.\n\n\nmandate.remarks\nYour agreement description\nThe description of the agreement that appears in the shopper agreement.\n\n\n\n\n \n\nThe response includes the mandate object with the same information that you sent in the request.\n\n \n\nThe shopper receives a notification from their bank (through SMS, email, or in their banking app) to authorize or decline the agreement.\nWhen the subscription agreement is accepted, you get the RECURRING_CONTRACT webhook that includes the recurringDetailReference for subsequent subscription payments.\n\nSubsequent subscription payments can only be performed with:\n\n\n Advanced flow \nAPI Only\n\n\nRequired webhooks\nThe following webhook notifications indicate the status of the transaction.\nOFFER_CLOSED\nThis notification will be returned when the agreement failed or is canceled by the user.\nIn this case, the refusalReasonRaw will be included in the additionalData object in the format errorCode:errorDescription. The contents of refusalReasonRaw will provide details about the reason for the failure or cancellation. Process the refusalReasonRaw to obtain more information about the decline or cancellation reason.\nAUTHORISATION\nYou will receive this notification for a payment on an accepted agreement, the payment outcome could be authorized or rejected.\nIn case the payment fails due to an error, you can consume the refusalReasonRaw that is returned in the additionalData object of your notification to get additional information about the reason for the payment being refused.\nREFUND\nWhen the refund is successfully received, the outcome will most likely succeed unless you receive a REFUND_FAILED notification.\nREFUND_FAILED\nBecause refunds are asynchronous events, the outcome might fail due to unexpected reasons. In such cases you will receive a REFUND_FAILED notification.\nRECURRING_CONTRACT\nContains the token in the payload of the notification sent to you in the pspReference parameter.\nDISABLE_RECURRING\nWhen an agreement arrives to term, or is canceled (by you or the shopper), you will receive a DISABLE_RECURRING notification to keep you informed about a token deletion.\nToken lifecycle webhooks are also supported.\nImport PayTo (optional)\nWhen you import Adyen Web, you can optionally import individual payment methods to optimize performance by using tree shaking. To do this, include PayTo.\n\n \nAdd additional configuration for PayTo\nYou do not need to add any configuration parameters for PayTo.\nTest and go live\nTo test, use the shopperAccountIdentifier with the following emails to simulate testing scenarios:\n\n\nType\nshopperAccountIdentifier\nResult\nDescription\n\n\nAgreement\n[Any valid input]\nAuthorised\nSuccessful payment.\n\n\nexpire@adyen-test.com\nOFFER_CLOSED\nThe Agreement has expired, please request your shopper to pay again.\n\n\ndebtor_account_type_not_supported@adyen-test.com\nOFFER_CLOSED\nThe agreement has been refused.\n\n\n\nPayment\n[Any valid input]\nAuthorised\nSuccessful payment.\n\n\ninsufficient_funds@adyen-test.com\nRefused\nInsufficient Funds\n\n\ndebtor_account_closed@adyen-test.com\nRefused\nThe Shopper account is closed.\n\n\nfinancial_infrastructure_unavailable@adyen-test.com\nError\nNPP is unable to process the payment due to back office issues or outage.\n\n","type":"page","locale":"pt","boost":17,"hierarchy":{"lvl0":"Home","lvl1":"Payment methods","lvl2":"PayTo","lvl3":"Web Drop-in"},"hierarchy_url":{"lvl0":"https:\/\/docs.adyen.com\/pt","lvl1":"https:\/\/docs.adyen.com\/pt\/payment-methods","lvl2":"https:\/\/docs.adyen.com\/pt\/payment-methods\/payto","lvl3":"\/pt\/payment-methods\/payto\/web-drop-in"},"levels":4,"category":"Payment method","category_color":"green","tags":["Drop-in"]},{"url":"https:\/\/docs.adyen.com\/pt\/payment-methods\/payto\/web-drop-in?flow=Sessions flow&integration=Drop-in","title":"Sessions flow Drop-in","content":"Requirements\n\n\n\nRequirement\nDescription\n\n\n\n\nIntegration type\nMake sure that you have an existing Sessions flow Web Drop-in integration.\n\n\n\nCheckout API\nMake sure that you use Checkout API v70 or later.\n \n\n\nSetup steps\nBefore you begin, add PayTo in your Customer Area.\n\n\n\nAdd additional parameters to your \/sessions request\nWhen you create a payment session, add the following parameters:\nThe additional parameters that you include depends on the type of PayTo payment.\n\nOne time payment\nSubscription setup and first payment\n\n\nSubsequent subscription payments can only be performed with:\n\n\n Advanced flow \nAPI Only\n\n\nOne-time payment\nTo offer one-time payments, add the following additional parameters.\n\n\n\nParameter\nRequired\nDescription\n\n\n\n\n shopperName.firstName\n\nThe shopper's first name.\n\n\n shopperName.lastName\n\nThe shopper's last name.\n\n\n shopperStatement\n\nThe text that shows up on the shopper's statement.\n\n\n lineItems.quantity\n\nFrom 0 to 9999.\n\n\n lineItems.sku\n\nUp to 200 characters.\n\n\n lineItems.description\n\nUsed to display the payment statement description to the shopper.Up to 280 characters. If multiple items, the item descriptions will be appended with a \",\" separator.\n\n\n lineItems.amountIncludingTax\n\nFrom 1 to 100000000.\n\n\n lineItems.itemCategory\n\nUp to 200 characters.\n\n\n\n reference\n\nThe reference to uniquely identify a payment. We recommend using a unique value per payment; however, it is not a requirement.Important: For PayTo, the maximum length is 35 characters.\n\n\n\n\n \n\nThe response includes the following.\n\n\n\nParameter\nDescription\n\n\n\n\nmandate.frequency\nadhoc\n\n\nmandate.endsAt\nThe end date. By default, it is set to one day after the payment request is sent.\n\n\nmandate.amount\nThe amount of the payment. It is the same as the amount sent in the payment request.\n\n\nmandate.amountRule\nexact\n\n\nmandate.count\n1\n\n\nmandate.remarks\nThe text that appears on the shopper's statement. By default, the text is One time payment.\n\n\n\n\n \n\nSubscription setup and first payment\nTo set up a subscription agreement with specific conditions and accept the first payment from the shopper, add the following parameters.\n\n\n\nParameter\nRequired\nDescription\n\n\n\n\n shopperName.firstName\n\nThe shopper's first name.\n\n\n shopperName.lastName\n\nThe shopper's last name.\n\n\n storePaymentMethod\n\nSet to true to store payment details for subscription payments.\n\n\n recurringProcessingModel\n\nSubscription\n\n\n shopperInteraction\n\nEcommerce\n\n\n mandate.frequency\n\nThe frequency with which a shopper should be charged.Possible values: adhoc, daily, weekly, biWeekly, monthly, quarterly, halfYearly, yearly.adhoc: Suitable for Card On File and Unscheduled Card On File recurring processing models.daily, weekly, biWeekly, monthly, quarterly, halfYearly, yearly: Suitable for Subscription recurring processing model.\n\n\n mandate.endsAt\n\nEnd date of the billing plan, in YYYY-MM-DD format.\n\n\n mandate.amount\n\nThe billing amount (in minor units) of the recurring transactions. 1 to 1000000000.\n\n\n mandate.amountRule\n\nThe limitation rule of the billing amount.Possible values:max: The transaction amount can not exceed the amount.exact: The transaction amount should be the same as the amount.\n\n\n mandate.remarks\n\nThe agreement description shown to the shopper up to 140 characters.\n\n\n mandate.count\n\nThe number of transactions that can be performed within the given frequency.Conditions:If the frequency is different than adhoc the count has to be provided and should be >= 1If frequency is adhoc the count can be omitted or will represent the total number of payments that can be done.\n\n\n mandate.startsAt\n\nStart date of the billing plan, in YYYY-MM-DD format. By default, the transaction date.\n\n\n lineItems.quantity \n 1\n\n\nFrom 0 to 9999.\n\n\n lineItems.sku \n 1\n\n\nUp to 200 characters. Note that this field is only available from v70 onwards.\n\n\n lineItems.description \n 1\n\n\nUsed to display the payment statement description to the shopper.Up to 280 characters. If multiple items, the item descriptions will be appended with a \",\" separator.\n\n\n lineItems.amountIncludingTax \n 1\n\n\nFrom 1 to 100000000.\n\n\n lineItems.itemCategory \n 1\n\n\nUp to 200 characters.\n\n\n reference\n\nThe reference to uniquely identify a payment. We recommend using a unique value per payment; however, it is not a requirement.Important: For PayTo, the maximum length is 35 characters.\n\n\n\n\n1 The lineItems information are consolidated and provided to PayTo as the payment description, and can be shown in the shopper's banking app (depending on the bank's capabilities).\n\nThe following example shows a request to create a session that offers the shopper a subscription agreement with a first payment of 30 AUD and a weekly payment of up to 90 AUD.\n\n\n\nParameter\nExample value\nDescription\n\n\n\n\namount.value\n3000\nAfter the shopper accepts the subscription agreement, they make a first, immediate payment of 30 AUD.\n\n\nmandate.frequency\nweekly\nA payment must be made weekly.\n\n\nmandate.amount\n9000\nThe amount of the weekly payment.\n\n\nmandate.amountRule\nmax\nThe maximum amount of the weekly payment is the mandate.amount of 90 AUD.\n\n\nmandate.count\n1\nThe shopper can make only one payment each week.\n\n\nmandate.endsAt\n2025-12-31\nThe subscription agreement ends on December 31, 2025.\n\n\nmandate.remarks\nYour agreement description\nThe description of the agreement that appears in the shopper agreement.\n\n\n\n\n \n\nThe response includes the mandate object with the same information that you sent in the request.\n\n \n\nThe shopper receives a notification from their bank (through SMS, email, or in their banking app) to authorize or decline the agreement.\nWhen the subscription agreement is accepted, you get the RECURRING_CONTRACT webhook that includes the recurringDetailReference for subsequent subscription payments.\n\nSubsequent subscription payments can only be performed with:\n\n\n Advanced flow \nAPI Only\n\n\nRequired webhooks\nThe following webhook notifications indicate the status of the transaction.\nOFFER_CLOSED\nThis notification will be returned when the agreement failed or is canceled by the user.\nIn this case, the refusalReasonRaw will be included in the additionalData object in the format errorCode:errorDescription. The contents of refusalReasonRaw will provide details about the reason for the failure or cancellation. Process the refusalReasonRaw to obtain more information about the decline or cancellation reason.\nAUTHORISATION\nYou will receive this notification for a payment on an accepted agreement, the payment outcome could be authorized or rejected.\nIn case the payment fails due to an error, you can consume the refusalReasonRaw that is returned in the additionalData object of your notification to get additional information about the reason for the payment being refused.\nREFUND\nWhen the refund is successfully received, the outcome will most likely succeed unless you receive a REFUND_FAILED notification.\nREFUND_FAILED\nBecause refunds are asynchronous events, the outcome might fail due to unexpected reasons. In such cases you will receive a REFUND_FAILED notification.\nRECURRING_CONTRACT\nContains the token in the payload of the notification sent to you in the pspReference parameter.\nDISABLE_RECURRING\nWhen an agreement arrives to term, or is canceled (by you or the shopper), you will receive a DISABLE_RECURRING notification to keep you informed about a token deletion.\nToken lifecycle webhooks are also supported.\nImport PayTo (optional)\nWhen you import Adyen Web, you can optionally import individual payment methods to optimize performance by using tree shaking. To do this, include PayTo.\n\n \nAdd additional configuration for PayTo\nYou do not need to add any configuration parameters for PayTo.\nTest and go live\nTo test, use the shopperAccountIdentifier with the following emails to simulate testing scenarios:\n\n\nType\nshopperAccountIdentifier\nResult\nDescription\n\n\nAgreement\n[Any valid input]\nAuthorised\nSuccessful payment.\n\n\nexpire@adyen-test.com\nOFFER_CLOSED\nThe Agreement has expired, please request your shopper to pay again.\n\n\ndebtor_account_type_not_supported@adyen-test.com\nOFFER_CLOSED\nThe agreement has been refused.\n\n\n\nPayment\n[Any valid input]\nAuthorised\nSuccessful payment.\n\n\ninsufficient_funds@adyen-test.com\nRefused\nInsufficient Funds\n\n\ndebtor_account_closed@adyen-test.com\nRefused\nThe Shopper account is closed.\n\n\nfinancial_infrastructure_unavailable@adyen-test.com\nError\nNPP is unable to process the payment due to back office issues or outage.\n\n","type":"page","locale":"pt","boost":17,"hierarchy":{"lvl0":"Home","lvl1":"Payment methods","lvl2":"PayTo","lvl3":"Web Drop-in"},"hierarchy_url":{"lvl0":"https:\/\/docs.adyen.com\/pt","lvl1":"https:\/\/docs.adyen.com\/pt\/payment-methods","lvl2":"https:\/\/docs.adyen.com\/pt\/payment-methods\/payto","lvl3":"\/pt\/payment-methods\/payto\/web-drop-in"},"levels":4,"category":"Payment method","category_color":"green","tags":["Sessions flow","Drop-in"]},{"url":"https:\/\/docs.adyen.com\/pt\/payment-methods\/payto\/web-drop-in?flow=Advanced flow&integration=Drop-in","title":"Advanced flow Drop-in","content":"Requirements\n\n\n\nRequirement\nDescription\n\n\n\n\nIntegration type\nMake sure that you have an existing Advanced flow Web Drop-in integration.\n\n\n\nCheckout API\nMake sure that you use Checkout API v70 or later.\n \n\n\nAction handling\nMake sure that your existing integration is set up to handle the additional action. action.type: await.\n\n\n\nSetup steps\nBefore you begin, add PayTo in your Customer Area.\n\n\n\nImport PayTo (optional)\nWhen you import Adyen Web, you can optionally import individual payment methods to optimize performance by using tree shaking. To do this, include PayTo.\n\n \nAdd additional configuration for PayTo\nYou do not need to add any configuration parameters for PayTo.\nAdd additional parameters to your \/payments request\nWhen you make a payment, add the following parameters:\nThe additional parameters that you include depends on the type of payment.\n\nOne time payment\nSubscription setup and first payment\nSubsequent subscription payment\n\nOne-time payment\nFor one-time payments, add the following additional parameters.\n\n\n\nParameter\nRequired\nDescription\n\n\n\n\n paymentMethod\n\npayto\n\n\n paymentMethod.shopperAccountIdentifier\n\nThe shopper's banking details or PayID reference, used to complete the payment. Possible values. 1\n\n\n\n shopperName.firstName\n\nThe shopper's first name.\n\n\n shopperName.lastName\n\nThe shopper's last name.\n\n\n shopperStatement\n\nThe text that shows up on the shopper's statement.\n\n\n lineItems.quantity\n\nThe number of items From 0 to 9999.\n\n\n lineItems.sku\n\nUp to 200 characters.\n\n\n lineItems.description\n\nUsed to display the payment statement description to the shopper.Up to 280 characters. If multiple items, the item descriptions will be appended with a \",\" separator.\n\n\n lineItems.amountIncludingTax\n\nFrom 1 to 100000000.\n\n\n lineItems.itemCategory\n\nUp to 200 characters.\n\n\n reference\n\nThe reference to uniquely identify a payment. We recommend using a unique value per payment; however, it is not a requirement.Important: For PayTo, the maximum length is 35 characters.\n\n\n\n\n \n\nThe response includes:\n\n \n\nSubscription setup and first payment\nTo set up a subscription agreement with specific conditions and accept the first payment from the shopper, add the following parameters.\n\n\n\nParameter\nRequired\nDescription\n\n\n\n\n paymentMethod\n\npayto\n\n\n paymentMethod.shopperAccountIdentifier\n\nThe shopper's banking details or PayID reference, used to complete the payment. Possible values. 1\n\n\n\n shopperName.firstName\n\nThe shopper's first name.\n\n\n shopperName.lastName\n\nThe shopper's last name.\n\n\n storePaymentMethod\n\nSet to true to store payment details for subscription payments.\n\n\n recurringProcessingModel\n\nSubscription\n\n\n shopperInteraction\n\nEcommerce\n\n\n mandate.frequency\n\nThe frequency with which a shopper should be charged.Possible values: adhoc, daily, weekly, biWeekly, monthly, quarterly, halfYearly, yearly.adhoc: Suitable for Card On File and Unscheduled Card On File recurring processing models.daily, weekly, biWeekly, monthly, quarterly, halfYearly, yearly: Suitable for Subscription recurring processing model.\n\n\n mandate.endsAt\n\nEnd date of the billing plan, in YYYY-MM-DD format.\n\n\n mandate.amount\n\nThe billing amount (in minor units) of the recurring transactions. 1 to 1000000000.\n\n\n mandate.amountRule\n\nThe limitation rule of the billing amount.Possible values:max: The transaction amount can not exceed the amount.exact: The transaction amount should be the same as the amount.\n\n\n mandate.remarks\n\nThe agreement description shown to the shopper, up to 140 characters.\n\n\n mandate.startsAt\n\nStart date of the billing plan, in YYYY-MM-DD format. By default, the transaction date.\n\n\n mandate.count\n\nThe number of transactions that can be performed within the given frequency.Conditions:If the frequency is different than adhoc the count has to be provided and should be >= 1If frequency is adhoc the count can be omitted or will represent the total number of payments that can be done.\n\n\n shopperStatement\n\nThe text that shows up on the shopper's statement. Appears in Mandate Remarks in one-off payment flow, if no Remarks are provided.\n\n\n lineItems.quantity \n 1\n\n\nFrom 0 to 9999.\n\n\n lineItems.sku \n 1\n\n\nUp to 200 characters. Note that this field is only available from v70 onwards.\n\n\n lineItems.description \n 1\n\n\nUsed to display the payment statement description to the shopper.Up to 280 characters. If multiple items, the item descriptions will be appended with a \",\" separator.\n\n\n lineItems.amountIncludingTax \n 1\n\n\nFrom 1 to 100000000.\n\n\n lineItems.itemCategory \n 1\n\n\nUp to 200 characters.\n\n\n reference\n\nThe reference to uniquely identify a payment. We recommend using a unique value per payment; however, it is not a requirement.Important: For PayTo, the maximum length is 35 characters.\n\n\n\n\n1 The lineItems information are consolidated and provided to PayTo as the payment description, and can be shown in the shopper's banking app (depending on the bank's capabilities).\n\nThe following example shows a payment request that gives the shopper a subscription agreement with a first payment of 30 AUD and a weekly payment of up to 90 AUD.\n\n\n\nParameter\nExample value\nDescription\n\n\n\n\namount.value\n3000\nAfter the shopper accepts the subscription agreement, they make a first, immediate payment of 30 AUD.\n\n\nmandate.frequency\nweekly\nA payment must be made weekly.\n\n\nmandate.amount\n9000\nThe amount of the weekly payment.\n\n\nmandate.amountRule\nmax\nThe maximum amount of the weekly payment is the mandate.amount of 90 AUD.\n\n\nmandate.count\n1\nThe shopper can make only one payment each week.\n\n\nmandate.endsAt\n2025-12-31\nThe subscription agreement ends on December 31, 2025.\n\n\nmandate.remarks\nYour agreement description\nThe description of the agreement that appears in the shopper agreement.\n\n\n\n\n \n\nThe response includes:\n\n \n\nThe shopper receives a notification from their bank (through SMS, email, or in their banking app) to authorize or decline the agreement.\nWhen the subscription agreement is accepted, you get the RECURRING_CONTRACT webhook that includes the recurringDetailReference for subsequent subscription payments.\nSubsequent subscription payment\nFor a subsequent subscription payment, add the following parameters.\n\n\n\nParameter\nRequired\nDescription\n\n\n\n\n paymentMethod\n\npayto\n\n\n paymentMethod.storedPaymentMethodId\n\nFrom the recurring.token.created webhook associated with the shopper, the data.storedPaymentMethodId. This stored payment method can only be used according to the conditions specified in the subscription agreement.\n\n\n shopperInteraction\n\nContAuth\n\n\n reference\n\nThe reference to uniquely identify a payment. We recommend using a unique value per payment; however, it is not a requirement.Important: For PayTo, the maximum length is 35 characters.\n\n\n\n\n \n\nThe response includes:\n\n \n\nShopper account identifiers\nThe following table shows the possible values you can use for the shopperAccountIdentifier parameter.\n\n\n\nIdentifier\nRegular expression (RegEx) for allowed values\n\n\n\n\nBSB-AccountNumber\n^\\d{6}-[ -~]{1,28}$`\n\n\nPayID Email\n^(?:[a-z0-9!#$%&'*+\\\/=?^_`{|}~-]+(?:\\.[a-z0-9!#$%&'*+\\\/=?^_`{|}~-]+)*@(?:[a-z0-9] (?:[a-z0-9-]*[a-z0-9])?\\.)+[a-z0-9] (?:[a-z0-9-]*[a-z0-9])?)$\n\n\nPayID Phone Number\n^\\+[0-9]{1,3}-[1-9]{1,1}[0-9]{1,29}$\n\n\nPayID ABN\n^((\\d{9})|(\\d{11}))$\n\n\nPayID Organisation Identifier\n^[!-@\\[-~][ -@\\[-~]{0,254}[!-@\\[-~]$\n\n\n\nRequired webhooks\nThe following webhook notifications indicate the status of the transaction.\nOFFER_CLOSED\nThis notification will be returned when the agreement failed or is canceled by the user.\nIn this case, the refusalReasonRaw will be included in the additionalData object in the format errorCode:errorDescription. The contents of refusalReasonRaw will provide details about the reason for the failure or cancellation. Process the refusalReasonRaw to obtain more information about the decline or cancellation reason.\nAUTHORISATION\nYou will receive this notification for a payment on an accepted agreement, the payment outcome could be authorized or rejected.\nIn case the payment fails due to an error, you can consume the refusalReasonRaw that is returned in the additionalData object of your notification to get additional information about the reason for the payment being refused.\nREFUND\nWhen the refund is successfully received, the outcome will most likely succeed unless you receive a REFUND_FAILED notification.\nREFUND_FAILED\nBecause refunds are asynchronous events, the outcome might fail due to unexpected reasons. In such cases you will receive a REFUND_FAILED notification.\nRECURRING_CONTRACT\nContains the token in the payload of the notification sent to you in the pspReference parameter.\nDISABLE_RECURRING\nWhen an agreement arrives to term, or is canceled (by you or the shopper), you will receive a DISABLE_RECURRING notification to keep you informed about a token deletion.\nToken lifecycle webhooks are also supported.\nTest and go live\nTo test, use the shopperAccountIdentifier with the following emails to simulate testing scenarios:\n\n\nType\nshopperAccountIdentifier\nResult\nDescription\n\n\nAgreement\n[Any valid input]\nAuthorised\nSuccessful payment.\n\n\nexpire@adyen-test.com\nOFFER_CLOSED\nThe Agreement has expired, please request your shopper to pay again.\n\n\ndebtor_account_type_not_supported@adyen-test.com\nOFFER_CLOSED\nThe agreement has been refused.\n\n\n\nPayment\n[Any valid input]\nAuthorised\nSuccessful payment.\n\n\ninsufficient_funds@adyen-test.com\nRefused\nInsufficient Funds\n\n\ndebtor_account_closed@adyen-test.com\nRefused\nThe Shopper account is closed.\n\n\nfinancial_infrastructure_unavailable@adyen-test.com\nError\nNPP is unable to process the payment due to back office issues or outage.\n\n","type":"page","locale":"pt","boost":17,"hierarchy":{"lvl0":"Home","lvl1":"Payment methods","lvl2":"PayTo","lvl3":"Web Drop-in"},"hierarchy_url":{"lvl0":"https:\/\/docs.adyen.com\/pt","lvl1":"https:\/\/docs.adyen.com\/pt\/payment-methods","lvl2":"https:\/\/docs.adyen.com\/pt\/payment-methods\/payto","lvl3":"\/pt\/payment-methods\/payto\/web-drop-in"},"levels":4,"category":"Payment method","category_color":"green","tags":["Advanced flow","Drop-in"]}]}