# Import payment method data Learn how to import your payment method data from your current payment processor to Stripe. #### Cards For general guidance on the standard migration process, see [Request a payment data import](https://docs.stripe.com/get-started/data-migrations/pan-import.md). This document offers supplemental information specifically for Card imports. When you migrate card data from your previous processor, you can import the data in Stripe as the default payment method card (`pm_`) object or a legacy card (`card_`) object. The Payment Intents API supports all Stripe products for both card payment types, but your integration might favor one based on the following considerations. - If you’re using a third-party subscription platform with Stripe, check with the platform or your developer to see if they prefer one or the other. - If you have existing payment data in your Stripe account, try to match the type you’re already using: - `pm_`: Use the [Payment Methods API](https://docs.stripe.com/api/payment-methods.md) in conjunction with the Payment Intents API. - `card_`: Use the [Card API](https://docs.stripe.com/api/cards.md) in conjunction with the Payment Intents API. - `src_`: You can still use the deprecated Sources API, but we recommend [migrating to the Payment Intents API](https://docs.stripe.com/payments/payment-intents/migration/charges.md) for access to more features. ## Default cards A *default card* is the primary card a customer sets or chooses for recurring payments, subscriptions, or as the default payment method for future transactions. When you mark a card as `default`, it automatically becomes the payment method for the next transaction unless you specify otherwise. Use this feature for subscription-based services that require automatic recurring payments. You can set a new card as the new default payment method, or add it as an additional payment method without changing the current default. | Type | Object prefix | Migration behavior | | -------------- | ------------- | ------------------------------------------------------------------------------------------------------------ | | Card | `card_` | Sets a default card on import. If unspecified in the data file, the first card imported becomes the default. | | Payment Method | `pm_` | Doesn’t require a default card. If unspecified in the data file, no card is the default. | | Source | `src_` | Doesn’t require a default card. If unspecified in the data file, no card is the default. | ### Provide default card data - Include default card information in a separate column of your data file, ideally using `TRUE` and `FALSE` values to identify the default and non-default cards. - Marking a card as default during import overrides an existing customer’s current default payment method, if set. ## Current limitations You can work with your Stripe representative to request Apple Pay DPAN migration to Stripe. Your previous processor must export the device primary account number (DPAN), expiration date, and network transaction ID. Stripe can’t migrate other cards stored by digital wallets such as Google Pay because those services (not the previous provider) tokenize the stored values for security. You must add any cards associated with digital wallets as new payment methods in Stripe. ## Address validation for Stripe Tax When you migrate customer data to an account using Stripe Tax, include customer address fields for the following reasons: - **Tax calculation accuracy**: Addresses help calculate taxes correctly in different jurisdictions. - **Compliance with tax laws**: Local tax laws require addresses for tax invoice accuracy. - **Audits and reporting**: Precise address data aids compliance in tax audits and enhances internal analytics by recording transaction locations. - **Enhanced customer checkout**: Starting with accurate addresses improves the checkout process for repeat customers by enabling precise, automatic tax calculation. - **Adaptability to tax law changes**: A full set of customer address data allows a business to adjust to tax regulation changes, preventing compliance issues. ## Card Account Updater (CAU) Files from processors often contain expired cards. Stripe’s Card Account Updater (CAU) automatically updates stored card information by retrieving and applying new card details from the issuing bank. CAU maximizes continuity of service and improves authorization rates, but might incur fees for each updated card in your account. You can specify how we handle expired cards during import. - **Skip expired cards**: Don’t import expired card data. CAU might still update non-expired cards (such as stolen or replacement cards), triggering post-migration charges. - **Import expired cards**: Allow CAU to update as many cards as possible and charge CAU fees to your account. ### How it works ![How card updating on import works](https://b.stripecdn.com/docs-statics-srv/assets/dm-cau.376a7292d021463b18118595e4e20e79.jpg) ## Migrate proof of Strong Customer Authentication (SCA) For European users, PSD2 (Second Payment Services Directive) mandates [Strong Customer Authentication (SCA)](https://docs.stripe.com/strong-customer-authentication.md) to enhance electronic payment security. SCA requires two out of three independent authentication factors for transactions: - Something the customer knows (such as a password) - Something the customer possesses (such as a mobile device) - Something the customer is (such as biometric data) Network transaction IDs from your previous processor show that a customer authenticated a transaction using SCA with the previous processor, enabling Stripe to apply for SCA exemptions for future transactions. This makes your migration to Stripe seamless for your customers, removing their need to re-authenticate. If your previous provider can’t supply transaction IDs, let us know in your [import request form](https://docs.stripe.com/get-started/data-migrations/pan-import.md#request-migration) so we can offer alternative options. ## 3DS mandate for Japanese Stripe accounts Japan’s revised [Credit Card Security Guidelines](https://www.meti.go.jp/press/2022/03/20230315001/20230315001.html) require Japanese businesses to enable 3D Secure 2 (3DS) by the end of March 2025. If you’re a Japanese business not using 3DS, report this in the **Additional Details** section of the [migration request form](https://docs.stripe.com/get-started/data-migrations/pan-import.md#request-migration). By default, we interpret this to mean you set the card up to be exempt from the [3DS Mandate in Japan requirement after migration](https://support.stripe.com/questions/3ds-mandate-in-japan). Stripe adjusts our support and services to help you comply with industry standards without disruption to your operations and security. Learn more about the [3DS Mandate in Japan](https://support.stripe.com/questions/3ds-mandate-in-japan). ## Card file guidance - A processor can provide a number of different fields. - We advise your processor to provide a full export of all customer and payment method data to Stripe. - Stripe can filter out any unnecessary fields from the previous processor’s data as needed. - Stripe can merge multiple received files if either the old customer ID or the old source ID is present in both files. ### File formatting requirements Export data files must meet the following data standards for us to proceed with an import: - The file must be in CSV format. - The file must be UTF-8 encoded. - Delimit rows by a single newline character `\n` (not `\r\n`). - Delimit columns by `,`. - You must wrap all fields containing commas in double quotes `"`. We recommend wrapping all fields in double quotes. - Leave empty fields entirely empty (no character in between delimiters). You must *not* denote a missing field with `NULL`, `N/A`, or any other value. - Escape any double quotes that are part of the content with another double quote per the CSV RFC. For example, format `William "Bard of Avon" Shakespeare` as `"William ""Bard of Avon"" Shakespeare"`. - Fields can’t contain newline characters (`\r` or `\n`) within a field. Example of what to avoid: `101 1st Ave\nApt 1` - All rows must have the same number of columns. - Columns support any order. - You must encrypt sensitive data files with our [PGP key](https://docs.stripe.com/get-started/data-migrations/pan-import.md#migration-pgp-key) before submitting through SFTP. ## Card data fields | Field | Required | Additional info | | ----------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Old customer ID | Required | We create a customer ID for each unique old customer ID provided. | | Card number | Required | Each customer imported must have at least one Card. | | Card expiry | Required | You can provide this option as one or two (separate month and year values) columns. | | Network Transaction IDs | Required* | \*Mandatory for [SCA impacted merchants](https://support.stripe.com/questions/countries-in-the-european-economic-area-\(eea\)-impacted-by-strong-customer-authentication-\(sca\)-regulation). | | Address line 1 | Required* | \*Recommended for address validation. Mandatory for Stripe Tax. | | City | Required* | \*Recommended for address validation. Mandatory for Stripe Tax. | | State | Required* | \*Recommended for address validation. Mandatory for Stripe Tax. | | Postal | Required* | \*Recommended for address validation. Mandatory for Stripe Tax. | | Country | Required* | \*Recommended for address validation. Mandatory for Stripe Tax. Format as the ISO 2 letter country code. | | Stripe customer ID | Optional | Provide in the processor file or a supplementary file to map to existing Stripe customers. | | Old card ID | Optional | Recommended if you have one customer with multiple cards in your old processor. | | Description | Optional | Additional metadata | | Email | Optional | Additional metadata | | Phone | Optional | Additional metadata | | Is default | Optional | Indicate `TRUE` or `FALSE` to specify whether the card is the default. | | Name | Optional | Additional metadata | | Address line 2 | Optional | Additional metadata | | Customer/Card Metadata | Optional | Any additional metadata | #### ACH For general guidance on the standard migration process, see [Request a payment data import](https://docs.stripe.com/get-started/data-migrations/pan-import.md). This document offers supplemental information specifically for [ACH Direct Debit](https://docs.stripe.com/payments/ach-direct-debit.md) imports. Nacha rules require you to obtain permission from a customer to take payments before you can debit their bank account. To get this permission, you must present a *mandate* (A written notice of authorization to debit a bank account, agreed to by the customer before the first debit) to them. When migrating ACH data from your previous processor, we can import the ACH records into Stripe using the legacy bank account (`ba_`) object or a payment method (`pm_`) object representation. Your submission of the intake form indicates your confirmation that you hold mandates for the bank accounts you’re importing for ACH debits. If you’re unsure, consult your previous payment service provider. If you don’t hold the mandates, please collect mandates from your customers before the import. ## ACH validation status You must confirm the validation status of the WEB debit accounts by choosing one of the options below: - **All** WEB debit accounts were validated according to the [Nacha WEB Debit Account Validation Rule](https://www.nacha.org/rules/supplementing-fraud-detection-standards-web-debits) by your previous payment service provider, or were debited before the Nacha WEB Debit Account Validation Rule took effect on March 19, 2021. - **None** of the WEB debit accounts were processed before the effective date of the [Nacha WEB Debit Account Validation Rule](https://www.nacha.org/rules/supplementing-fraud-detection-standards-web-debits) on March 19, 2021, nor successfully validated by your previous provider. Stripe must validate these accounts. (An [instant verification fee](https://stripe.com/pricing/local-payment-methods#ach-direct-debit) applies per bank account validation.) ## How it works ![Shows the ACH record import process ](https://b.stripecdn.com/docs-statics-srv/assets/dm-ach.98cba192b8fbc5201ba77d81f815e86c.jpg) ## ACH emails In our [intake form](https://support.stripe.com/contact/email?topic=migrations), choose whether to import the mandates as bank account (`ba_`) or payment method (`pm_`) objects. - If you choose bank accounts, we don’t notify your customers about the migration. - If you choose payment methods and provide customer emails, we’ll automatically send your customers an email to confirm the mandate in accordance with Nacha requirements after the import. Your customers don’t need to do anything after receiving the emails. ## ACH file guidance - A processor can provide a number of different fields. - We advise your processor to provide a full export of all customer and payment method data to Stripe. - Stripe can filter out any unnecessary fields from the previous processor’s data as needed. - Stripe can merge multiple received files if either the old customer ID or the old source ID is present in both files. ### File formatting requirements Export data files must meet the following data standards for us to proceed with an import: - The file must be in CSV format. - The file must be UTF-8 encoded. - Delimit rows by a single newline character `\n` (not `\r\n`). - Delimit columns by `,` - You must wrap all fields containing commas in double quotes `"`. We recommend wrapping all fields in double quotes. - Leave empty fields entirely empty (no character in between delimiters). You must *not* denote a missing field with `NULL`, `N/A`, or any other value. - Escape any double quotes that are part of the content with another double quote per the CSV RFC. For example: `"``William` `""``Bard of Avon``""` `Shakespeare``"` - Fields can’t contain newline characters (`\r` or `\n`) within a field. Example of what to avoid: `101 1st Ave\nApt 1` - All rows must have the same number of columns. - Columns support any order. - You must encrypt sensitive data files with our [PGP key](https://docs.stripe.com/get-started/data-migrations/pan-import.md#migration-pgp-key) before submitting through SFTP. ## ACH data fields | Field | Required | Additional info | | --------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Old customer ID | Required | We create a customer ID for each unique old customer ID provided. | | Routing number | Required | Must be 9 digits in length and include leading zeros. | | Account number | Required | Most bank account numbers have between 8 and 12 digits, though they can range from 5 to 17 digits. | | Account holder type | Required | Specifies `individual` or `company` as the type of business. | | Account type | Required | Specifies a `checking` or `savings` account. Unspecified account are imported as `checking`. | | Account name | Required | First and last name of account holder or company name. | | Email | Optional* | Additional metadata *If importing ACH records as payment methods and providing customer emails, we’ll automatically send your customers an email to confirm the mandate in accordance with Nacha requirements after the import. Your customers don’t need to do anything after receiving the emails. | | City | Optional | Additional metadata | | Postal | Optional | Additional metadata | | Country | Optional | Provide in ISO 2 letter country code format. | | Phone | Optional | Additional metadata | | Address line 1 | Optional | Additional metadata | | State | Optional | Additional metadata | | Stripe customer ID | Optional | Additional metadata | | Old source ID | Optional | Additional metadata | | Customer/ACH Metadata | Optional | Any additional metadata | ## ACH Data Migration Certification and Disclaimer Language By submitting the [ACH Data Migration intake form](https://support.stripe.com/contact/email?topic=migrations), you certify that all of the following statements are true and that you have authority to make these statements. You acknowledge that you hold mandates that specify the terms for recurring payments for the bank accounts you want to import. You collected the mandates through the internet or a wireless network. You agree to comply with Section 2.3 of the [Nacha Operating Rules](https://nachaoperatingrulesonline.org) in connection with collecting authorizations when using Stripe services to process ACH Debit transactions. You understand that you, as the Originator (as defined in the Nacha Operating Rules), are solely responsible for collecting and retaining ACH Debit authorizations from your customers that comply with the Nacha Operating Rules and Stripe’s [ACH Payment Method Terms](https://stripe.com/en-de/legal/ACH). For recommended text, see the Stripe [ACH documentation](https://docs.stripe.com/payments/ach-direct-debit.md#recommended-mandate-text). If you don’t meet the Nacha Operating Rules requirements for the authorization of debits, you understand that you must collect new authorizations before processing ACH Debit transactions on Stripe. For authorizations collected prior to migration to Stripe, you must provide Stripe with evidence of any relevant authorization for ACH Debits upon request. When contesting a dispute, you’re solely responsible for providing a copy of the authorization. #### Bacs Stripe users in the UK can accept Bacs Direct Debit payments from customers with a UK bank account. You can migrate your data from your current payment processor to your Stripe account using the Bacs bulk change process. We work with other payment processors and Bacs sponsor banks throughout the migration to securely migrate your Bacs data. A Bacs migration takes approximately 6 weeks to complete. To export Bacs data from Stripe to another payment processor, see [Export Bacs data from Stripe](https://docs.stripe.com/payments/bacs-debit/export-data.md). ## Before you begin Before migrating, complete the following account setup: - Activate the Bacs Direct Debit payment method in the Stripe [Dashboard](https://dashboard.stripe.com/settings/payment_methods). - Decide which Service User Number (SUN) to use: - **Stripe shared SUN**: A free SUN that uses Stripe’s name and branch on statements, payment sheets, and emails. - **Custom SUN**: For a monthly fee, you can subscribe to [Custom Branding](https://docs.stripe.com/payments/payment-methods/bacs-debit.md#custom-branding) and use a custom SUN to show your business name and brand on statements, payment sheets, and emails. - Collect the following details required for the migration request form: - Bacs SUN with current processor - Your preference for shared or custom SUN on Stripe - The number of mandates you’re migrating to Stripe - Whether you’re requesting migration on behalf of a connected account ## Submit your Bacs import migration request Start the migration process by submitting a data migration request: 1. Navigate to the [Stripe Support form for data migrations](https://support.stripe.com/contact/email?topic=migrations). If you’re not signed in, select **Sign in** and enter the credentials of the account that you want to migrate your data to. 1. Select **Import data from a third party into a Stripe account**. 1. Select **Bacs** as the data type you want to import. 1. Complete the remaining fields and select **Send email**. Within three days of receiving your request, our Data Migrations team emails you to request a signed bulk change deed. ## Complete the bulk change deed To complete the migration, your current Bacs processor must sign a bulk change deed. This agreement authorizes the transfer of your mandates from your current payment processor to Stripe. Sign in to download the bulk change deed. The following template highlights the requirements of a bulk change deed for an import of Bacs data to Stripe. ![bulk change deed template with highlighted requirements](https://docs.stripecdn.com/image.412a76360aea7f98c3a42fdf1a84e0a3dfe6b3dd301cedcd122b1d13344f866e.png) One of the following sets of representatives from your current processor must sign the bulk change deed: - Two current SUN owner directors - A director and a witness - A director and a company secretary Directors and company secretaries need to be publicly identifiable through public data sources, such as [Companies House](https://www.gov.uk/government/organisations/companies-house). If you’re using a witness’s signature, cross out the **Secretary/Director** label as pictured in the template. Complete only section 1.1 and the **To be completed by the Current Service User** section. Leave **New Service User** and **New Sponsoring Bank** sections blank and don’t date the document in section 3.3. Marks on the document such as staples, staple holes, or other amendments invalidate the bulk change deed. After completing the bulk change deed, reply to the intake form email thread from our Data Migrations team with a scan of it. ## Coordinate your bulk change timeline After we receive your bulk change deed, Stripe’s Data Migrations team works with you, your current payment processor, and our sponsor bank to agree on a bulk change date. On the bulk change date, Stripe imports your mandates and customers into your Stripe account. We recommend scheduling your bulk change date at least 6 weeks from the date you submit the signed bulk change deed to us. The following process must complete in advance of the bulk change date: - Agreement between all parties on a bulk change date - Stripe completes a Notification of Change form - Review and approval of documents by Stripe and current sponsor banks - Advance notice sent to customers about the bulk change - Transfer of data to Stripe and preparation of the import If you need to complete the migration in multiple phases, let us know in the support email thread. We’ll work with you to set different bulk change dates for each phase. ## Send letters to payers The *Letter to Payers* explains why you need the migration, how it affects payers, and the Direct Debit Guarantee. Download the pre-approved Letter to Payers template. Inform us if you need to edit the Letter to Payers. Any modifications require a review by Stripe’s sponsor bank. Sign in to download the Letter to Payers template. You can decide how to deliver the Letter to Payers to your customers. Email, mail, and text message are all valid communication options. Not alerting payers to this change can result in failed payments and disputes. ### Communication timing Wait until after you receive final approval for the bulk change from the sponsor banks to send the Letter to Payers. You must send the Letter to Payers in accordance with the **Advance Notice Period** in your current SUN. Contact your current processor to confirm your Advance Notice Period. Your customer might see two active mandates in their banking portal for 1-3 business days while Stripe completes the import of your existing mandates. ## Import Bacs mandates After we receive bulk change approval from the sponsor banks, we coordinate with you and your current processor to transfer the relevant customer and mandate data. Stripe reviews the data received from your current processor and identifies any problems with the import. We work with you and your current processor to correct any issues. We then share a summary of the import for your final review and approval. Your current payment processor must cancel your existing mandates before we execute the import on the bulk change date. After cancellation: - You can’t charge your customers using your current processor. - We execute the mandate import on the bulk change date and email you a confirmation after completion. - We create a `Customer` with an associated BACS `PaymentMethod` for each unique customer in the transferred data file. The following table shows the Bacs timeline in business days (T) from the bulk change date to the time you receive funds in your account: | | | | | T+0 | Migration complete and mandate submitted | | T+3 | Mandate is active and the payment is submitted | | T+5 | Funds leave the customer’s bank account | | T+7 | Funds are available in Stripe | ### File formatting requirements Export data files must meet the following data standards for us to proceed with an import: - The file must be in CSV format. - The file must be UTF-8 encoded. - Delimit rows by a single newline character `\n` (not `\r\n`). - Delimit columns by `,` - You must wrap all fields containing commas in double quotes `"`. We recommend wrapping all fields in double quotes. - Leave empty fields entirely empty (no character in between delimiters). You must *not* denote a missing field with `NULL`, `N/A`, or any other value. - Escape any double quotes that are part of the content with another double quote per the CSV RFC. For example: `"``William` `""``Bard of Avon``""` `Shakespeare``"` - Fields can’t contain newline characters (`\r` or `\n`) within a field. Example of what to avoid: `101 1st Ave\nApt 1` - All rows must have the same number of columns. - Columns support any order. - You must encrypt sensitive data files with our [PGP key](https://docs.stripe.com/get-started/data-migrations/pan-import.md#migration-pgp-key) before submitting through SFTP. ## Bacs data fields | Field | Required | Additional info | | ------------------------ | -------- | -------------------------------------------------------------------------------------------------------------------------------- | | Old customer ID | Required | We create a customer ID for each unique old customer ID provided. | | Name | Required | Must include the first and last name of the person on the mandate. | | Sort code | Required | Must be 6 digits in length and include leading zeros. | | Account number | Required | Must be 8 digits in length and include leading zeros. | | Email | Required | Stripe requires your customer’s email so we can send out notifications. Contact us if your customers don’t have email addresses. | | Address line 1 | Required | First line of the address for the customer’s Bacs mandate. | | City | Required | City address for the customer’s Bacs mandate. | | Postal | Required | Zip code of the address for the customer’s Bacs mandate. | | Country | Required | Must be in the form of the ISO 2 letter country code. | | Phone | Optional | Phone number of the account holder. | | Address line 2 | Optional | Secondary details of the address for the customer’s Bacs mandate. | | State | Optional | State of the address for the customer’s Bacs mandate. | | DDI date | Optional | Additional metadata (date the Bacs mandate was created). | | Date of first collection | Optional | Additional metadata (date the mandate was first charged). | | Stripe customer ID | Optional | Stripe customer ID to map the mandates to if required. | | Old source ID | Optional | Unique representation of a payment method. | | Customer/Bacs Metadata | Optional | Any additional metadata. | #### SEPA For general guidance on the standard migration process, see [Request a payment data import](https://docs.stripe.com/get-started/data-migrations/pan-import.md). This document offers supplemental information specifically for SEPA imports. Stripe migrates all SEPA payment data as payment methods. This guide provides instructions for migrating your existing SEPA mandates from your previous payment processors into Stripe. ## Importing the mandates In the context of SEPA, mandates refer to the original authorized agreement that the customer and the business have already established. In Stripe, *creating a new mandate object* doesn’t mean creating a new mandate from scratch. On import, we create a new *mandate object* that: - Uses the same `mandate_reference` as your original agreement. - Represents the same agreement the customer initially authorized for the first direct debit instruction. No new information is required from the customer. The original agreement stays the same. ### Creditor ID A SEPA Creditor Identifier (Creditor ID) is an ID associated with each SEPA Direct Debit payment that identifies the company requesting the payment. While companies might have multiple creditor identifiers, each creditor identifier is unique and allows your customers to identify the debits on their account. By default, your Stripe account uses a Stripe Creditor ID when collecting SEPA Direct Debit Payments. **Stripe Payments** appears on bank statements alongside your configurable [Stripe statement descriptor](https://docs.stripe.com/get-started/account/statement-descriptors.md). We recommend that you: - Configure a recognizable statement descriptor to make sure customers recognize payments and to reduce the risk of disputes. - Use your own Creditor ID to reduce dispute rates and improve your customer’s recognition of their payment to you. - If you’re using the Stripe Creditor ID, use Stripe Checkout to collect mandates from your customers for SEPA Direct Debits. You can configure your own Creditor ID in the [Payment Method Settings](https://dashboard.stripe.com/settings/payment_methods) page. When using your own Creditor ID, your name appears on statements instead of Stripe’s. #### Example SEPA Bank Mandate if using Stripe’s Creditor ID ``` From Account Account name: CURRENT-ACCOUNT BIC: BANBICKIEXXXXX IBAN: IE11BANK11111111111111 Originator Details Originator name: Stripe Payments Europe Ltd Creditor Identifier: BE111111111111 The Creditor Identifier is a unique identifier used by the company to process collections. UMR: UMR123 PSP The Unique Mandate Reference (UMR) is specific to the mandate you have signed and identifies each direct debit mandate. Additional details Status: Active ``` #### Example SEPA Bank Mandate if using your own Creditor ID ``` From Account Account name: CURRENT-ACCOUNT BIC: BANBICKIEXXXXX IBAN: IE11BANK11111111111111 Originator Details Originator name: Merchant Creditor ID Name Creditor Identifier: BE222222222222 The Creditor Identifier is a unique identifier used by the company to process collections. UMR: UMR123 PSP The Unique Mandate Reference (UMR) is specific to the mandate you have signed and identifies each direct debit mandate. Additional details Status: Active ``` ## Migration notification Inform your customers about the migration before it happens. They don’t need to give permission again or set up a new SEPA Direct Debit mandate. The approval you already have is sufficient. ### General guidelines for communication: Point out any changes such as: - Creditor ID if you opt for Stripe’s Creditor ID - Creditor name if you opt for Stripe’s Creditor ID - Recipient bank IBAN Make sure the communication reassures customers their current mandates are valid without requiring any action from them, unless they choose to cancel the mandate. ## SEPA debit notification SEPA rules state that you must [notify your customers](https://docs.stripe.com/payments/sepa-debit.md#debit-notification-emails) when debiting their SEPA payment method. By default, Stripe automatically sends these email notifications on your behalf. ## SEPA file guidance - A processor can provide a number of different fields. - We advise your processor to provide a full export of all customer and payment method data to Stripe. - Stripe can filter out any unnecessary fields from the previous processor’s data as needed. - Stripe can merge multiple received files if either the old customer ID or the old source ID is present in both files. ### File formatting requirements Export data files must meet the following data standards for us to proceed with an import: - The file must be in CSV format. - The file must be UTF-8 encoded. - Delimit rows by a single newline character `\n` (not `\r\n`). - Delimit columns by a comma (`,`). - You must wrap all fields containing commas in double quotes (`"`). We recommend wrapping all fields in double quotes. - Leave empty fields entirely empty (no character in between delimiters). You must *not* denote a missing field with `NULL`, `N/A`, or any other value. - Escape any double quotes that are part of the content with another double quote per the CSV RFC. Example: `"``William` `""``Bard of Avon``""` `Shakespeare``"` - Fields can’t contain newline characters (`\r` or `\n`) within a field. An example of what to avoid would be: `101 1st Ave\nApt 1`. - All rows must have the same number of columns. - Columns support any order. - You must encrypt sensitive data files with our [PGP key](https://docs.stripe.com/get-started/data-migrations/pan-import.md#migration-pgp-key) before submitting them through SFTP. ### SEPA data Fields | Field | Required | Additional info | | ---------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Old customer ID | Required | We create a customer ID for each unique old customer ID provided. | | Name | Required | We must include the name of the person on the mandate. | | IBAN | Required | Follow Stripe’s valid IBAN structure. | | Mandate reference | Required | Existing mandate reference ID | | Email | Required | SEPA requires you to email a notification to the customer upon debiting their SEPA payment method. Stripe can send this email notification automatically or you can manually send it. | | Address line 1 | Required* | \*Mandatory for non EU IBANs | | Country | Required* | \*Mandatory for non EU IBANs. This must be in the form of the ISO 2 letter country code. | | Postal | Optional | Additional metadata | | Country | Optional | Additional metadata | | Phone | Optional | Additional metadata | | Address line 2 | Optional | Additional metadata | | State | Optional | Additional metadata | | Stripe customer ID | Optional | Additional metadata | | Old source ID | Optional | Additional metadata | | Customer/SEPA Metadata | Optional | Any additional metadata | #### PADs For general guidance on the standard migration process, see [Request a payment data import](https://docs.stripe.com/get-started/data-migrations/pan-import.md). This document offers supplemental information specifically for PADs imports. [Payments Canada Rules for pre-authorized debits](https://www.payments.ca/sites/default/files/h1eng.pdf) (PADs) require businesses to present a mandate agreement with clear and specific terms for one-time or recurring debits prior to debiting a customer’s bank account. After you collect customer agreement, this [mandate](https://docs.stripe.com/payments/acss-debit.md#mandates) gives your business authorization to debit the customer’s bank account on a specified schedule. The mandate includes the customer’s institution number, transit number, account number, name and email. Stripe can only import the PADs that you confirm you hold the mandates for. Your submission of the intake form indicates your confirmation that you hold mandates for the PADs you’re importing. ## Migration notification You must notify your customers that you’re migrating payment processing to Stripe. ## Debit PADs In our [intake form](https://support.stripe.com/contact/email?topic=migrations), choose how you’ll debit the PADs: - **Only for automatic** use with invoices, subscriptions, or recurring payment schedules. - **Only for on-demand** customer-initiated payments. You can’t debit these PADs for automatic use with invoices, subscriptions, or recurring payment schedules. - **For both** on-demand customer-initiated payments and automatic use with invoices, subscriptions, or recurring payment schedules. ## PADs file guidance - A processor can provide a number of different fields. - We advise your processor to provide a full export of all customer and payment method data to Stripe. - Stripe can filter out any unnecessary fields from the previous processor’s data as needed. - Stripe can merge multiple received files if either the old customer ID or the old source ID is present in both files. - Stripe can only import PADs that are pre-authorized because verification is a requirement of ACSS scheme rules. ### File formatting requirements Export data files must meet the following data standards for us to proceed with an import: - The file must be in CSV format. - The file must be UTF-8 encoded. - Delimit rows by a single newline character `\n` (not `\r\n`). - Delimit columns by `,` - You must wrap all fields containing commas in double quotes `"`. We recommend wrapping all fields in double quotes. - Leave empty fields entirely empty (no character in between delimiters). You must *not* denote a missing field with `NULL`, `N/A`, or any other value. - Escape any double quotes that are part of the content with another double quote per the CSV RFC. For example: `"``William` `""``Bard of Avon``""` `Shakespeare``"` - Fields can’t contain newline characters (`\r` or `\n`) within a field. Example of what to avoid: `101 1st Ave\nApt 1` - All rows must have the same number of columns. - Columns support any order. - You must encrypt sensitive data files with our [PGP key](https://docs.stripe.com/get-started/data-migrations/pan-import.md#migration-pgp-key) before submitting through SFTP. ## PADs data fields | Field | Required | Additional info | | ----------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | | Old customer ID | Required | We create a customer ID for each unique old customer ID provided. | | Institution Number | Required | The 3-digit institution number identifies your bank. | | Transit Number | Required | The transit number (5 digits) identifies the branch where you opened your account. | | Account Number | Required | The account number (7-12 digits) identifies your individual account. | | Account holder name | Required | First and last name of account holder or company name. | | Email | Required/Optional1 | Additional metadata (Optional if full address is provided instead). | | Address line 1 | Required/Optional1 | Additional metadata (Optional if email is provided instead). | | Address line 2 | Required/Optional1 | Additional metadata (Optional if email is provided instead). | | City | Required/Optional1 | Additional metadata (Optional if email is provided instead). | | State | Required/Optional1 | Additional metadata (Optional if email is provided instead). | | Postal | Required/Optional1 | Additional metadata (Optional if email is provided instead). | | Country | Required/Optional1 | Additional metadata (Optional if email is provided instead). | | Transaction Type | Required | Specifies whether the account is `personal` or `business`. | | [Payment Schedule](https://docs.stripe.com/payments/acss-debit.md#payment-schedule) | Required | Specifies whether the schedule is `interval`, `sporadic`, or `combined`. | | Interval Description | Required only if `payment_schedule` is specified as `interval` or `combined` | Text description of the payment schedule interval. | | Phone | Optional | Additional metadata | | Stripe customer ID | Optional | Additional metadata | | Old source ID | Optional | Additional metadata | | Description | Optional | Additional metadata | | Customer metadata | Optional | Any additional metadata | 1 Either the customer email address or their full address must be present within the data file to import PADs/ACSS. If you provide neither an email address nor a full address, the PAD fails to import. ## PADs Data Migration Certification and Disclaimer Language By submitting the [PADs through ACSS Data Migration intake form](https://support.stripe.com/contact/email?topic=migrations), you certify that all of the following statements are true and that you have authority to make these statements. You hold mandates for all of the PADs payment methods you’re importing. You agree to comply with [Rule H1](https://www.payments.ca/sites/default/files/h1eng.pdf) of Payments Canada and the other [Rules](https://www.payments.ca/systems-services/rules-documentation?field_rules_type=170&field_category_type=All) of Payments Canada that supplement Rule H1 (“PAD Rules”) when using Stripe services to process Pre-Authorized Debits (“PADs”). You understand that you, as the Payee (as defined in the PAD Rules), are solely responsible for collecting and retaining PAD authorizations from your customers that comply with the PAD Rules, as described in Stripe’s [ACSS Payment Method Terms](https://stripe.com/en-de/legal/pad) and [mandate agreement requirements](https://docs.stripe.com/payments/acss-debit/custom-pad-agreement.md#mandate-agreement-requirements). If you don’t meet the PAD rules requirements for previously-collected authorizations, you understand that you must collect new authorizations before processing PADs on Stripe. For authorizations collected prior to migration to Stripe, you must provide Stripe with evidence of any relevant authorization for PAD transactions upon request. When contesting a dispute, you’re solely responsible for providing a copy of the authorization. #### BECS For general guidance on the standard migration process, see [Request a payment data import](https://docs.stripe.com/get-started/data-migrations/pan-import.md). This document offers supplemental information specifically for [AU BECS](https://docs.stripe.com/payments/au-becs-debit.md) imports. When you migrate AU BECS data from your previous processor, you import the data in Stripe as a payment method object (`pm_`). ## Import the mandates During the customer onboarding process, businesses must collect a mandate that authorizes them to debit the account. In the BECS Direct Debit system, these mandates are called Direct Debit Requests (DDRs). These mandates or DDRs refer to the original authorized agreement that the customer and the business have already established. In migrating payment details to Stripe, we create a new Direct Debit Request for you to replace your existing direct debit request mandates. This new DDR: - Represents the same agreement the customer initially authorized for the first direct debit instruction. - Requires no new information from the customer. The original agreement stays the same. ### Account limits New users are subject to default limits of 10,000 AUD per transaction and 10,000 AUD per week for Australia BECS Direct Debit transactions. If you need higher limits, let us know in your [migration request form](https://docs.stripe.com/get-started/data-migrations/pan-import.md#request-migration). ## Migration notification Inform your customers about the migration at least 30 days before the first debit through Stripe. Their original approval is sufficient, but you must: - Inform customers that you’re updating their existing Direct Debit Request (DDR) and [Direct Debit Request Service Agreement (DDRSA)](https://stripe.com/au-becs-dd-service-agreement/legal). - Include a link to the new Direct Debit Request Service Agreement (DDRSA). Reassure your customers that their current mandates are valid and they don’t need to give permission again or set up a new AU BECS Direct Debit mandate, unless they choose to cancel the mandate. ## AU BECS debit notification AU BECS regulations advises you to [notify your customers](https://docs.stripe.com/payments/au-becs-debit.md#debit-notification-emails) when debiting their AU BECS payment method. If you choose to notify your customers, you can have Stripe automatically send this email notification, or you can send it manually. Stripe requires the customer email address in the migration data to comply with this regulation. ## AU BECS file guidance - A processor can provide a number of different fields. - We advise your processor to provide a full export of all customer and payment method data to Stripe. - Stripe can filter out any unnecessary fields from the previous processor’s data as needed. - Stripe can merge multiple received files if either the old customer ID or the old source ID is present in both files. ## File formatting requirements Export data files must meet the following data standards for us to proceed with an import: - The file must be in CSV format. - The file must be UTF-8 encoded. - Delimit rows by a single newline character `\n` (not `\r\n`). - Delimit columns by a comma (`,`). - You must wrap all fields containing commas in double quotes (`"`). We recommend wrapping all fields in double quotes. - Leave empty fields entirely empty (no character in between delimiters). You must not denote a missing field with `NULL`, `N/A`, or any other value. - Escape any double quotes that are part of the content with another double quote per the CSV RFC. Example: `"William` `""Bard of Avon""` `Shakespeare"` - Fields can’t contain newline characters (`\r` or `\n`) within a field. An example of what to avoid would be: `101 1st Ave\nApt 1`. - All rows must have the same number of columns. - Columns support any order. - You must encrypt sensitive data files with our [PGP key](https://docs.stripe.com/get-started/data-migrations/pan-import.md#migration-pgp-key) before submitting them through SFTP. ## AU BECS data fields | Field | Required | Additional info | | ------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Old customer ID | Required | We create a customer ID for each unique old customer ID provided. | | Name | Required | We must include the name of the person on the mandate. | | Account Number | Required | The bank account number. | | BSB Number | Required | The 6 digit bank state branch number of the bank account. | | Email | Required | AU BECS requires you to email a notification to the customer upon signup and debit of their AU BECS payment method. Stripe can send this email notification automatically or you can manually send it. | | Stripe customer ID | Optional | Stripe customer ID to map the mandates to if required. | | Old source ID | Optional | Unique representation of a payment method. | | Address line 1 | Optional | First line of the address for the customer’s AU BECS mandate. | | Address line 2 | Optional | Secondary details of the address for the customer’s AU BECS mandate. | | City | Optional | City address for the customer’s AU BECS mandate. | | State | Optional | State of the address for the customer’s AU BECS mandate. | | Postal | Optional | Zip code of the address for the customer’s AU BECS mandate. | | Country | Optional | Must be in the form of the ISO 2 letter country code. | | Phone | Optional | Phone number of the account holder. | | Customer/AU BECS Metadata | Optional | Any additional metadata. | ## Review migration output During import, we inspect your source file, validate data formatting, and generate an output file. You receive an error log with all [errors and a post import mapping file](https://docs.stripe.com/get-started/data-migrations/pan-import.md#post-import-mapping-file) that links your source data to new customer data in your Stripe account, in CSV or JSON format. We also add `old_id` [metadata](https://docs.stripe.com/metadata.md) to [Customer](https://docs.stripe.com/api/customers.md) objects.