# Wise Platform API The Wise Platform API is a REST-based interface that enables programmatic access to Wise's payment infrastructure. All endpoints return JSON-formatted responses and use standard HTTP methods and status codes. {% admonition type="success" name="New to wise?" %} We strongly recommend first reading our **[Getting Started Guide](/guides/developer/index.md)** to help you set up credentials and make your first call. {% /admonition %} Before you begin {% .title-2 .m-t-5 %} To use this API reference effectively, you should have: - Received Valid [API credentials from Wise](/guides/developer/auth-and-security/index.md) (Client ID and Client Secret) - Understand OAuth 2.0 authentication - Be familiar with RESTful API concepts Core API resources {% .title-2 .m-t-5 .m-b-0 %} | Resource | Purpose | |----------|---------| | **[Quote](/api-reference/quote)** | Exchange rate and fee calculations | | **[Recipient](/api-reference/recipient)** | Beneficiary account management | | **[Transfer](/api-reference/transfer)** | Payment creation and execution | | **[Balance](/api-reference/balance)** | Multi-currency account operations | | **[Profile](/api-reference/profile)** | Account ownership details | | **[Rate](/api-reference/rate)** | Current and historical exchange rates | **Not sure which workflow to build?**
Start with our [Integration Guides](/guides/product/send-money/use-cases/index.md) for step-by-step implementation examples.{% .m-t-3 .m-b-5 %} ## Servers Production Environment ``` https://api.wise.com ``` Sandbox Environment ``` https://api.wise-sandbox.com ``` ## Security ### UserToken User Access Token for making API calls on behalf of a Wise user. Can be obtained via two OAuth 2.0 flows: - **registration_code grant**: For partners creating users via API - **authorization_code grant**: For partners using Wise's authorization page Access tokens are valid for 12 hours and can be refreshed using a refresh token. Type: http Scheme: bearer Bearer Format: JWT ### PersonalToken Personal API Token for individual personal or small business users. Generated from Wise.com > Settings > Integrations and Tools > API tokens. Has limited API access compared to OAuth tokens (PSD2 restrictions apply for EU/UK users). Type: http Scheme: bearer Bearer Format: JWT ### ClientCredentialsToken Application-level token for partner operations that don't require a specific user context, such as bulk settlement and card spend controls. Obtained via `POST /oauth/token` with Basic Authentication (client-id:client-secret) and `grant_type=client_credentials`. Valid for 12 hours. No refresh token — fetch a new token when expired. See [create an OAuth token](/api-reference/oauth-token/oauthtokencreate) for details. Type: http Scheme: bearer Bearer Format: JWT ### BasicAuth Basic Authentication using your Client ID and Client Secret as the username and password. Client credentials are provided by Wise when your partnership begins. See [Getting Started](/guides/developer) for details. Type: http Scheme: basic ## Download OpenAPI description [Wise Platform API](https://docs.wise.com/_bundle/api-reference/index.yaml) ## 3D Secure Authentication To manage certain aspects of the 3D Secure (3DS) authentication, you will need to integrate with the following APIs. ### Inform challenge result - [POST /v3/spend/profiles/{profileId}/3dsecure/challenge-result](https://docs.wise.com/api-reference/3ds/3dschallengeresultpost.md): Once the customer has accepted or rejected the push notification for a 3DS challenge, you can use this endpoint to notify us of the result. You must call this endpoint before the expiration time, otherwise it will return a 400 error. You can find the expiration information from the 3DS challenge webhook event. Only the first call to this endpoint will be processed. Any subsequent duplicate requests will be ignored, although you will still receive a success response. {% admonition type="warning" %} This endpoint is SCA protected when it applies. If your profile is registered within the UK and/or EEA, SCA most likely applies to you. For more information, please read implementing SCA. {% /admonition %} ## Activity Activity represents a snapshot of a performed action for a profile. ### List Activities for a Profile - [GET /v1/profiles/{profileId}/activities](https://docs.wise.com/api-reference/activity/activitylist.md): List of activities belonging to user profile. Activities represent snapshots of performed actions and can be filtered by various parameters to narrow down the results. ## Additional Customer Verification In certain situations, additional evidence is required to verify customers and ensure we’re compliant with the KYC regulations. Additional Verification APIs support a list of evidences that can be found in the [Supported Evidences guide](/guides/product/kyc/partner-kyc/supported-evidences). If you use the [Customer Account with Partner KYC](/guides/product/kyc/partner-kyc) model and your customers are primarily based in the EU, refer to this [Onboarding EU customers](/guides/product/kyc/partner-kyc/additional-verification#onboarding-eu-customers) guide for instructions on how to use these APIs. If you use the [Customer Account with Partner KYC](/guides/product/kyc/partner-kyc) model and you are onboarding high risk business customers based primarily based in the US, refer to this [Onboarding High Risk US Businesses](/guides/product/kyc/partner-kyc/additional-verification#onboarding-high-risk-us-businesses) guide for instructions on how to use these APIs. ### Upload Evidences - [POST /v5/profiles/{profileId}/additional-verification/upload-evidences](https://docs.wise.com/api-reference/verification/verificationuploadevidences.md): Uploads verification evidence for a specific profile. The request body varies significantly between Personal and Business profiles. Submitting an evidence that was already uploaded will result in an attempt to update the evidence. ### Upload Document - [POST /v3/profiles/{profileId}/verification-status/upload-document](https://docs.wise.com/api-reference/verification/verificationuploaddocument.md): Uploads verification documents for review. You can upload multiple files at once. A valid document must fulfil these requirements: - The document must be clear. - The document needs to be a .jpg, .png., or .pdf file type up to 10MB in size. ### Required Evidences - [GET /v3/profiles/{profileId}/verification-status/required-evidences](https://docs.wise.com/api-reference/verification/verificationgetrequiredevidences.md): Fetches the required evidences for a profile to complete additional customer verification. If one or more evidences are returned, the customer should submit those evidences using the upload-evidences endpoint. See the Supported Evidences guide for the list of possible evidence types and how to submit them. ### Upload Evidences (v3) (deprecated) - [POST /v3/profiles/{profileId}/additional-verification/upload-evidences](https://docs.wise.com/api-reference/verification/verificationuploadevidencesv3.md): Uploads verification evidence for a specific profile. The request body varies significantly between Personal and Business profiles. ## Address Manage physical addresses associated with user profiles. Address requirements vary by country — use the address requirements endpoints to dynamically discover which fields are needed before creating an address. ### Create or Update an Address - [POST /v1/addresses](https://docs.wise.com/api-reference/address/addresscreate.md): Adds address info to user profile. List of required fields are different for different countries. Use the address requirements endpoint to dynamically discover required fields. For updating personal profiles, consider using the personal profile update endpoint instead. It allows submitting the address information alongside other profile data. State field is required for US, CA, BR, and AU addresses. Occupations is required for CA, IN, JP, ID, IL, MX, and within the US for the state NM. ### List Addresses for a Profile - [GET /v1/addresses](https://docs.wise.com/api-reference/address/addresslist.md): List of addresses belonging to user profile. ### Retrieve an Address by ID - [GET /v1/addresses/{addressId}](https://docs.wise.com/api-reference/address/addressget.md): Get address info by ID. ### Get Address Requirements - [GET /v1/address-requirements](https://docs.wise.com/api-reference/address/addressrequirementsget.md): Returns the list of fields required to create a valid address. Use this as a starting point to discover required fields. The response contains 4 required top-level fields: - country (select field with list of values) - city (text field) - postCode (text field) - firstLine (text field) If a field has refreshRequirementsOnChange: true, call the POST endpoint with that field's value to discover additional required fields. For a step-by-step walkthrough, see the Address Requirements guide. ### Get Address Requirements (with context) - [POST /v1/address-requirements](https://docs.wise.com/api-reference/address/addressrequirementspost.md): Returns the list of fields required to create a valid address, based on the provided context. Use this endpoint to dynamically discover additional required fields based on selected values. For example: - Posting {"details": {"country": "US"}} will add "state" to the list of fields. - Posting {"details": {"country": "CA"}} will add "occupations" to the list of fields. Continue calling this endpoint with field values until all fields with refreshRequirementsOnChange: true have been populated. For a step-by-step walkthrough, see the Address Requirements guide. ## Balance Create and manage balance accounts within a multi-currency account. Each profile can hold multiple balance accounts in different currencies. A `STANDARD` balance is limited to one per currency, while `SAVINGS` balances (Jars) allow multiple in the same currency. Creating the first balance for a profile automatically creates the multi-currency account. Balances include an `investmentState` field. Only balances with `NOT_INVESTED` can be operated on via the API. Invested balances should be shown but not actionable. For a complete guide on multi-currency accounts, see [Multi-Currency Accounts](/guides/product/accounts). ### Create a Balance Account - [POST /v4/profiles/{profileId}/balances](https://docs.wise.com/api-reference/balance/balancecreate.md): Opens a balance within the specified profile, in the currency and type specified in the request. For STANDARD balances, only one can be created per currency. For SAVINGS balances, multiple in the same currency can be opened. When creating a SAVINGS type balance, a name is required. ### List Balances for a Profile - [GET /v4/profiles/{profileId}/balances](https://docs.wise.com/api-reference/balance/balancelist.md): Retrieves the user's multi-currency account balance accounts. Returns all balance accounts the profile has in the types specified. The types parameter must include at least one type. To return more than one type, comma-separate the values. ### Retrieve a Balance by ID - [GET /v4/profiles/{profileId}/balances/{balanceId}](https://docs.wise.com/api-reference/balance/balanceget.md): Returns a balance based on the specified balance ID. ### Remove a Balance Account - [DELETE /v4/profiles/{profileId}/balances/{balanceId}](https://docs.wise.com/api-reference/balance/balancedelete.md): Closes a balance account for the user's profile. Balance accounts must have a zero balance to be closed. Bank account details for the balance will also be deactivated and may not be restored. ### Convert or Move Money Between Balances - [POST /v2/profiles/{profileId}/balance-movements](https://docs.wise.com/api-reference/balance/balancemovement.md): This endpoint allows conversion and movement of funds between balance accounts. Convert across balance accounts: Convert funds between two STANDARD balance accounts in different currencies. Requires a quote created with "payOut": "BALANCE". Move money between balances: - Add money to a same-currency jar (move from STANDARD to SAVINGS without conversion) - Add money to another-currency jar (convert money using a quote) - Withdraw money from a jar (move from SAVINGS to STANDARD without conversion) Either amount or quoteId is required. Use quoteId for cross-currency movements. ### Retrieve Deposit Limits - [GET /v1/profiles/{profileId}/balance-capacity](https://docs.wise.com/api-reference/balance/balancecapacity.md): Returns the deposit limit for a profile based on regulatory requirements. Useful for personal profiles located in countries that have hold limits. We advise calling this API before depositing money into an account if the profile is located in Singapore or Malaysia. ### Add an Excess Money Account - [POST /v1/profiles/{profileId}/excess-money-account](https://docs.wise.com/api-reference/balance/excessmoneyaccount.md): If a balance goes over the regulatory hold limit, excess funds are automatically moved to another account at the end of the day. Use this endpoint to specify a recipient where excess money will be transferred. Primarily used for Singapore and Malaysia customers. ### Get Total Funds - [GET /v1/profiles/{profileId}/total-funds/{currency}](https://docs.wise.com/api-reference/balance/totalfunds.md): Provides an overview of your account's total valuation and available liquidity across all balances. Returns total worth, total available (including overdraft), total cash, and overdraft details. #### Example (Assuming GBP and USD has 1:1 exchange rate) | Scenario | GBP balance | USD balance | Total Worth | Total Available | Overdraft Usage | Overdraft Limit | | ---------------------------------------- | ----------- | ----------- | ----------- | --------------- | --------------- | --------------- | | Positive account value with no overdraft | 2000 | 0 | 2000 | 2000 | 0 | 0 | | Positive account value with overdraft | 2000 | -100 | 1900 | 2400 | 100 | 500 | | Negative account value with overdraft | 0 | -100 | -100 | 400 | 100 | 500 | ### Get account balance (v1) (deprecated) - [GET /v1/borderless-accounts](https://docs.wise.com/api-reference/balance/balancegetv1.md): {% admonition type="warning" %} This endpoint is deprecated. Use the v4 Balances endpoint instead. {% /admonition %} Get available balances for all activated currencies in your multi-currency account. ### Convert currencies between balances (v1) (deprecated) - [POST /v1/borderless-accounts/{borderlessAccountId}/conversions](https://docs.wise.com/api-reference/balance/balanceconvertv1.md): {% admonition type="warning" %} This endpoint is deprecated. Use the balance movements endpoint to move and convert between balances instead. {% /admonition %} Convert funds between your multi-currency account currencies. Quote which is used in this call must be created with "payOut": "BALANCE". Note that this call needs an extra field in header called X-idempotence-uuid. ## Balance Statement Balance statements contain transactional activities on a Wise Multi-Currency Account, including deposits, withdrawals, conversions, card transactions, and fees. Statements can be retrieved in multiple formats: JSON, CSV, PDF, XLSX, CAMT.053, MT940, or QIF. ### Get Balance Statement - [GET /v1/profiles/{profileId}/balance-statements/{balanceId}/statement.json](https://docs.wise.com/api-reference/balance-statement/balancestatementget.md): Retrieve a statement for the specified balance account. The response format depends on the URL path: - statement.json - JSON format - statement.csv - CSV format - statement.pdf - PDF format (includes Wise branding) - statement.xlsx - Excel format - statement.xml - CAMT.053 XML format - statement.mt940 - MT940 format - statement.qif - QIF format The period between intervalStart and intervalEnd cannot exceed 469 days (around 1 year 3 months). {% admonition type="warning" %} This endpoint is SCA protected when it applies. If your profile is registered within the UK and/or EEA, SCA most likely applies to you. The additional authentication is only required once every 90 days, viewing the statement on the website or in the mobile app counts towards that as well. Learn more {% /admonition %} ## Bank Account Details Bank account details allow users to receive money into their Wise Multi-Currency Account. Each currency balance can have local bank details (for domestic payments) and international bank details (for SWIFT payments) where available. Bank account details can be retrieved for existing balances, or new details can be ordered for currencies where they're available but not yet issued. ### Create bank account details order - [POST /v1/profiles/{profileId}/account-details-orders](https://docs.wise.com/api-reference/bank-account-details/bankaccountdetailsordercreate.md): Creates an order which will issue account details. It should use the same currency as the balance previously created. Fulfilling all the requirements will complete the order, reaching status DONE. The possible values for a requirement status are: - PENDING_USER: The requirement has some pending action from the user. - PENDING_TW: The requirement has some pending action from Wise. - DONE: The requirement is completed. The more common requirements are: - VERIFICATION: The user needs to be fully verified before completing this requirement. - TOP_UP: A fee will be charged and must be paid through wise.com before completing this requirement. ### Create multiple bank account details - [POST /v3/profiles/{profileId}/bank-details](https://docs.wise.com/api-reference/bank-account-details/bankaccountdetailsbankdetailscreate.md): Creates and assigns a pair of local account details and international account details (where available) that are linked to the target balance specified in the request. {% admonition type="warning" %} Please reach out to our Support Team for access to this endpoint. {% /admonition %} ### Retrieve bank account details - [GET /v1/profiles/{profileId}/account-details](https://docs.wise.com/api-reference/bank-account-details/bankaccountdetailsget.md): Returns a list with all the AVAILABLE and ACTIVE account details for the given profile, including examples. Account receive options can also include local and international details to receive money on the currency balance. Example bank account details are returned for any currency where bank account details have not been requested and issued. Examples will always include an id of null. ### List bank account detail orders - [GET /v3/profiles/{profileId}/account-details-orders](https://docs.wise.com/api-reference/bank-account-details/bankaccountdetailsorderslist.md): Returns the bank account assignment requests for a profile and multi-currency account. The response includes bank-details orders in the following statuses: PENDING_USER, PENDING_TW, REQUIREMENTS_FULFILLED, DONE. ### Create payment return - [POST /v1/profiles/{profileId}/account-details/payments/{paymentId}/returns](https://docs.wise.com/api-reference/bank-account-details/bankaccountdetailsreturnscreate.md): Creates a return for a payment received to bank account details. When you create a return, you must provide the ID of the payment you wish to return as well as the ID of the profile that received the payment. In addition, you can provide a reason for the return in the request body. When returning SWIFT payments, reason is a required field. ### List bank account detail orders (v1) (deprecated) - [GET /v1/profiles/{profileId}/account-details-orders](https://docs.wise.com/api-reference/bank-account-details/bankaccountdetailsorderslistv1.md): Returns the bank account assignment requests for a profile and multi-currency account. {% admonition type="warning" %} This endpoint is deprecated. Please use the v3 endpoint instead. {% /admonition %} ## Batch Group A batch group is a named collection of up to 1000 transfers that can be managed as a single unit. Batch groups are primarily used for funding multiple transfers with a single payment. **Workflow:** 1. Create a batch group with a source currency 2. Add transfers to the group (up to 1000) 3. Complete the batch group to close it for modifications 4. Fund the batch group from a balance or via direct debit Individual transfers in the group follow standard transfer lifecycle and can be tracked separately. ### Create a batch group - [POST /v3/profiles/{profileId}/batch-groups](https://docs.wise.com/api-reference/batch-group/batchgroupcreate.md): Create a new batch group. A batch group can hold up to 1000 transfers that will be funded together. After creating the group, add transfers to it, then complete the group to receive pay-in details. ### Retrieve a batch group - [GET /v3/profiles/{profileId}/batch-groups/{batchGroupId}](https://docs.wise.com/api-reference/batch-group/batchgroupget.md): Get an existing batch group by ID. ### Update batch group status - [PATCH /v3/profiles/{profileId}/batch-groups/{batchGroupId}](https://docs.wise.com/api-reference/batch-group/batchgroupupdate.md): Update a batch group's status to complete or cancel it. Complete a batch group: Set status to COMPLETED to close the group for modifications and allow funding to proceed. Once completed, payInDetails will be populated with funding instructions. Cancel a batch group: Set status to CANCELLED to cancel all transfers in the batch. Only batches that are not funded can be cancelled. Cancellation is final and cannot be undone. The version parameter is required for concurrency control. The operation will be rejected if the provided version does not match the server's current version. ### Create a batch group transfer - [POST /v3/profiles/{profileId}/batch-groups/{batchGroupId}/transfers](https://docs.wise.com/api-reference/batch-group/batchgrouptransfercreate.md): Create a transfer in the batch group using a previously created recipient account and quote. For the request body format, see transfer creation. For quote and recipient creation, see quote creation and recipient creation. ### Fund a batch group - [POST /v3/profiles/{profileId}/batch-payments/{batchGroupId}/payments](https://docs.wise.com/api-reference/batch-group/batchgroupfund.md): Funds all transfers in a batch group from a multi-currency account balance. Transfers are paid out immediately. The batch group must first be completed, and there must be enough funds in the account for the whole batch. Otherwise, an insufficient funds error will be returned. {% admonition type="warning" %} This endpoint is SCA protected when it applies. If your profile is registered within the UK and/or EEA, SCA most likely applies to you. For more information, please read implementing SCA. {% /admonition %} ### Fund a batch group via direct debit - [POST /v1/profiles/{profileId}/batch-groups/{batchGroupId}/payment-initiations](https://docs.wise.com/api-reference/batch-group/batchgrouppaymentinitiationcreate.md): Funds all transfers in a batch group via direct debit. The batch group must be in the COMPLETED state. To use this funding method, you need to link an external bank account first. See direct debit account creation for more information. {% admonition type="warning" %} This endpoint is SCA protected when it applies. If your profile is registered within the UK and/or EEA, SCA most likely applies to you. For more information, please read implementing SCA. {% /admonition %} ### Retrieve a payment initiation - [GET /v1/profiles/{profileId}/batch-groups/{batchGroupId}/payment-initiations/{paymentInitiationId}](https://docs.wise.com/api-reference/batch-group/batchgrouppaymentinitiationget.md): Get payment initiation info by ID. In addition to webhooks, this endpoint can be used for polling the status of a payment initiation. ## Bulk Settlement Bulk settlement allows partners to settle multiple transfers in a single bank transfer at the end of a settlement period. This model splits transfer creation/funding from final settlement, allowing Wise to process transfers before receiving funds based on a partner's guarantee. Use the settlement journal endpoint to submit a list of transfers to be settled, along with the settlement reference that matches your bank transfer payment. ### Send a settlement journal - [POST /v1/settlements](https://docs.wise.com/api-reference/bulk-settlement/bulksettlementjournalcreate.md): Sends the settlement journal to Wise. There are two types of settlement: - Same Currency Settlement — Settle in the same currency as the transfers (e.g., settle USD transfers with USD). - Cross Currency Settlement — Settle in a different currency (e.g., settle PHP transfers with USD). In this case, you must specify settlementCurrency and include exchangeRate on every transfer. {% admonition type="info" %} You must use a client credentials token to authenticate this call. {% /admonition %} ## Card Manage your customers' cards programmatically. These APIs allow you to retrieve card details, control card status, manage spending permissions, and access sensitive card data securely. **Key capabilities:** - List and retrieve card details for a profile - Update card status (active, frozen, blocked) - Control spending permissions (e-commerce, ATM, contactless, etc.) - Access sensitive card data (PAN, CVV, PIN) via encrypted JWE payloads **Sensitive card details:** Wise is a PCI DSS compliant provider and stores all card data securely. The scope for PCI compliance depends on your use case and will impact how you integrate. For all sensitive card details endpoints, follow the [detailed guide](/guides/product/issue-cards/sensitive-card-details). {% admonition type="info" %} For ordering new cards, see the [Card Order API](/api-reference/card-order). For transaction history, see the [Card Transaction API](/api-reference/card-transaction). {% /admonition %} ### List cards for a profile - [GET /v3/spend/profiles/{profileId}/cards](https://docs.wise.com/api-reference/card/cardlist.md): Returns a paginated list of cards that belong to a specific profile. ### Get card details - [GET /v3/spend/profiles/{profileId}/cards/{cardToken}](https://docs.wise.com/api-reference/card/cardget.md): Retrieves details for a specific card by its token. ### Update card status - [PUT /v3/spend/profiles/{profileId}/cards/{cardToken}/status](https://docs.wise.com/api-reference/card/cardstatusupdate.md): Update the status of a card. For cards issued with an INACTIVE status, updating to ACTIVE will activate the card and move the card order status to COMPLETED. Available status transitions: - ACTIVE - The card is active and usable - FROZEN - The card is temporarily frozen; all authorization requests will be declined - BLOCKED - The card is irreversibly blocked and is no longer usable ### Reset PIN count - [POST /v3/spend/profiles/{profileId}/cards/{cardToken}/reset-pin-count](https://docs.wise.com/api-reference/card/cardpincountreset.md): If the wrong PIN has been entered more than 3 times, future transactions on the card will be blocked with a PIN_ENTRY_TRIES_EXCEEDED error message. Use this endpoint to reset the PIN count to 0 and unblock transactions. {% admonition type="info" %} In some cases, you may also need to reset the PIN count directly at the ATM. {% /admonition %} ### Get card spending permissions - [GET /v3/spend/profiles/{profileId}/cards/{cardToken}/spending-permissions](https://docs.wise.com/api-reference/card/cardpermissionsget.md): Retrieves the current spending permissions configured for a card. ### Update a single card permission - [PATCH /v3/spend/profiles/{profileId}/cards/{cardToken}/spending-permissions](https://docs.wise.com/api-reference/card/cardpermissionsupdate.md): Enable or disable a single spending permission on a card. For bulk updates, use the v4 endpoint instead. ### Bulk update card permissions - [PATCH /v4/spend/profiles/{profileId}/cards/{cardToken}/spending-permissions](https://docs.wise.com/api-reference/card/cardpermissionsbulkupdate.md): Enable or disable multiple spending permissions on a card in a single request. This is the recommended endpoint for updating card permissions as it allows updating multiple permissions atomically. ### Fetch RSA encryption key - [GET /twcard-data/v1/clientSideEncryption/fetchEncryptingKey](https://docs.wise.com/api-reference/card/cardencryptionkeyget.md): Fetches Wise's RSA public key required for encrypting sensitive card data requests. This key is used in the sensitive card details flow to create JWE (JSON Web Encryption) payloads. ### Get sensitive card details - [POST /twcard-data/v1/sensitive-card-data/details](https://docs.wise.com/api-reference/card/cardsensitivedetailsget.md): Fetches the card's Primary Account Number (PAN), security code (CVV2), expiry date, and cardholder name. Requires an encrypted JWE payload for security. See the sensitive card details guide for implementation details. To retrieve sensitive card details, the card must be in either ACTIVE or FROZEN status. A 403 response will be returned for cards in any other status. {% admonition type="warning" %} This endpoint is SCA protected when applicable. If your profile is registered within the UK and/or EEA, SCA most likely applies. For more information, see implementing SCA. {% /admonition %} ### Get card PIN - [POST /twcard-data/v1/sensitive-card-data/pin](https://docs.wise.com/api-reference/card/cardpinget.md): Fetches the card's PIN. Requires an encrypted JWE payload for security. See the sensitive card details guide for implementation details. {% admonition type="warning" %} This endpoint is SCA protected when applicable. If your profile is registered within the UK and/or EEA, SCA most likely applies. For more information, see implementing SCA. {% /admonition %} ### Update phone number (deprecated) - [PUT /v3/spend/profiles/{profileId}/cards/{cardToken}/phone-number](https://docs.wise.com/api-reference/card/cardphonenumberupdate.md): {% admonition type="warning" %} This endpoint is deprecated for partners onboarded after 1/3/2025. For new and existing partners, your clientId will need to be approved by our support team to make the phoneNumber optional in the create card order endpoint. See 3DS for more information. {% /admonition %} Updates the phone number of a card. The new phone number must be a valid phone number. ## Card Kiosk Collection These APIs are designed to allow you to print and encrypt your card directly from a kiosk machine. The card information will be sent to our card manufacturer to configure and print the card on-site on a kiosk machine. The card printing process will automatically begin once the request is received by our card manufacturer. During the printing process, you will be notified via webhook about any [card production status change](/guides/developer/webhooks/event-types#cards-card-production-status-change). Before using these APIs, make sure to read the guide on [kiosk collection](/guides/product/issue-cards/card-kiosk-collection#card-kiosk-collection). {% admonition type="warning" %} Please reach out to your Implementation Manager for more information on these APIs. {% /admonition %} **Testing**: In the sandbox environment, use the [card production simulation API](/api-reference/simulation/simulationcardproduction) to test your integration with various production statuses and error scenarios. Production status flow {% .title-2 .m-t-5 %} These statuses represent the lifecycle of a card production: - `READY` - Card is ready for production. The [produce card endpoint](/api-reference/card-kiosk-collection/cardkioskcollectionproduce) can be called. - `IN_PROGRESS` - Card is being produced at the kiosk machine (chip encryption and printing in progress). - `PRODUCED` - Card has been successfully produced and collected from the kiosk. This is a final state. - `PRODUCTION_ERROR` - Card production failed. Check the errorCode to identify the issue, resolve it, then retry using the [produce card endpoint](/api-reference/card-kiosk-collection/cardkioskcollectionproduce). A card with production status `PRODUCED` will trigger an asynchronous call to update the associated card order to `PRODUCED` status. ![Card production status flow](/images/diagrams/card-production-status-flow.png) ### Produce a card - [PUT /v3/spend/profiles/{profileId}/cards/{cardToken}/production](https://docs.wise.com/api-reference/card-kiosk-collection/cardkioskcollectionproduce.md): Sends the card production request to a kiosk machine. To confirm that card information has been successfully created, listen to the card-production-status-change webhook with status READY. {% admonition type="warning" %} Cards that were created over 60 days ago will result in a 422 error code and cannot be retried. This is due to the data being obfuscated on our side. In this case, a new card order has to be created. {% /admonition %} ### Retrieve card production status - [GET /v3/spend/profiles/{profileId}/cards/{cardToken}/production](https://docs.wise.com/api-reference/card-kiosk-collection/cardkioskcollectionproductionget.md): Retrieves the current production status of a card at a kiosk machine. Best practice: Subscribe to the card production status change webhook for real-time notifications. Use this endpoint only when you need to synchronously check the status. ## Card Order With this set of APIs, you will be able to create cards for your customers. You can also retrieve and view the status of your current card orders, as well as the list of available card programs for the user. {% admonition type="info" %} On production, each personal profile can order at most 1 physical card and 3 virtual cards. On sandbox, we allow up to 10 physical cards and 30 virtual cards for testing purpose. However, no more than 3 virtual cards can be ordered per day. This limit includes cards and card orders. {% /admonition %} Card order status flow {% #card-order-status-flow .title-3 .m-t-5 %} The card order response will contain the `status` field. The initial status is `PLACED` or `REQUIREMENTS_FULFILLED` depending on the requirement fulfillment state: - `PLACED` - The card order is created. The card will be generated once it has fulfilled all the requirements - `REQUIREMENTS_FULFILLED` - The card order has fulfilled all the requirements and the card should be generated in a short while - `CARD_DETAILS_CREATED` - The card has been generated - `PRODUCED` - The physical card has been produced and waiting to be picked up by delivery vendor (physical card only) - `COMPLETED` - The card has been activated and is ready to use. The card order is completed - `CANCELLED` - The card order has been cancelled. This can happen if you reach out to Wise Support to cancel a card order - `RETURNED` - Delivery failed, the physical card has been returned and will be blocked (physical card only) ![Card order status state machine](/images/diagrams/card-order-status-flow.png) ### Create a card order - [POST /v3/spend/profiles/{profileId}/card-orders](https://docs.wise.com/api-reference/card-order/cardordercreate.md): Creates a new card order. The program field value is retrieved from the retrieve all card programs endpoint. {% admonition type="warning" %} This request requires an extra field in the header, X-idempotence-uuid. This should be generated and used for any subsequent retries in the event that the initial request fails. {% /admonition %} When you issue a card under a business profile, the cardholder will automatically default to the business representative. If the cardholder is not the business representative, create a cardholder personal profile and add the profileId of the cardholder profile to the cardHolderProfileId field on the card order request. For country-specific address fields and validation rules, see the card address validation guide. ### Retrieve all card orders - [GET /v3/spend/profiles/{profileId}/card-orders](https://docs.wise.com/api-reference/card-order/cardorderlist.md): Retrieves a list of card orders created for the specified profileId. ### Retrieve a card order - [GET /v3/spend/profiles/{profileId}/card-orders/{cardOrderId}](https://docs.wise.com/api-reference/card-order/cardorderget.md): Retrieves a card order based on the cardOrderId. ### Retrieve available card programs - [GET /v3/spend/profiles/{profileId}/card-orders/availability](https://docs.wise.com/api-reference/card-order/cardorderprogramsget.md): Retrieves the list of available card programs for each profileId. ### Retrieve card order requirements - [GET /v3/spend/profiles/{profileId}/card-orders/{cardOrderId}/requirements](https://docs.wise.com/api-reference/card-order/cardorderrequirementsget.md): Retrieves all card requirements for a cardOrderId. A valid card order needs all its requirements status to be COMPLETED. The type of requirements are: - PIN (optional): Set a PIN on a virtual or physical card order. Contact the team if you need this feature. - VERIFICATION: Verify your customer by providing KYC evidences. Refer to the KYC guide. - ADDRESS: Provide a valid address for your card order. Refer to address validation. A requirement status has the following values: - NOT_INITIATED - NEEDS_ACTION - PENDING - COMPLETED - FAILED ### Update card order status - [PUT /v3/spend/profiles/{profileId}/card-orders/{cardOrderId}/status](https://docs.wise.com/api-reference/card-order/cardorderstatusupdate.md): Updates the status of a card order based on its cardOrderId. The status can be updated to one of the following: 1. CANCELLED 2. COMPLETED (deprecated) The behaviour for card order cancellation differs across card order statuses: - PLACED: Card order can be cancelled with no further action required. - REQUIREMENTS_FULFILLED, CARD_DETAILS_CREATED, PRODUCED: Card order can be cancelled, and its associated card will be blocked. However, the physical card may have already been produced and may be in delivery. If so, the card will still reach the end user's address. This should be communicated to the end user to prevent confusion. - COMPLETED, RETURNED: Card orders in these statuses cannot be cancelled. {% admonition type="info" %} Updating a card order status to COMPLETED is deprecated. Check with our team whether this is supported in your integration. {% /admonition %} ### Validate an address - [POST /v3/spend/address/validate](https://docs.wise.com/api-reference/card-order/cardordervalidateaddress.md): Validates the format of an address for a card order. Make sure to follow country-specific address fields and validation as described in the card address validation guide. For virtual cards, the address field will be used as a billing address. It will be used for AVS checks in countries where it is required. For physical cards, the address field will be used as a delivery address. It will be used to deliver your card and for AVS checks in countries where it is required. {% admonition type="warning" %} We do not support PO BOX addresses. {% /admonition %} ### Set card PIN - [POST /twcard-data/v1/sensitive-card-data/preset-pin](https://docs.wise.com/api-reference/card-order/cardorderpresetpin.md): Sets a PIN during the card order flow. This endpoint will be accessible for partners that require to set a PIN during the card order flow. Please follow this guide to use this endpoint. To use this endpoint, make sure to set the api token and the card order id in the headers. ## Card Transaction Retrieve information on transactions made on your users' cards. Transaction types {% #card-transaction-type .title-3 .m-t-5 %} The possible `type` values are: - `ACCOUNT_CREDIT` - Receiving money on the card, excluding Visa OCT or Mastercard MoneySend - `ACCOUNT_FUNDING` - Sending money to another card or e-wallet - `CASH_ADVANCE` - Cash disbursement - `CASH_WITHDRAWAL` - ATM withdrawal - `CHARGEBACK` - Currently unused. Reserved for future use - `CREDIT_TRANSACTION` - Visa OCT and Mastercard MoneySend - `ECOM_PURCHASE` - Online purchase - `POS_PURCHASE` - Purchase via a POS terminal - `REFUND` - Partial or full refund of an existing card transaction Transaction states {% #card-transaction-state .title-3 .m-t-5 %} The possible `state` values are: - `IN_PROGRESS` - The transaction has been authorized but not captured - `COMPLETED` - The transaction has been captured and/or settled - `DECLINED` - The transaction has been declined - `CANCELLED` - The transaction has been cancelled - `UNKNOWN` - Default fallback status if the state cannot be confirmed The transition from `CANCELLED` to `COMPLETED` is an edge case. Wise releases the customer funds after 7 days (30 days for pre-authorization) if the merchant has not captured the transaction, and the state becomes `CANCELLED`. However, the merchant can decide to capture the transaction at a later date, at which point the state will become `COMPLETED`. ![Transaction state flow](/images/diagrams/transaction-state-flow.png) Decline reasons {% #card-transaction-decline-reasons .title-3 .m-t-5 %} The decline reason field provides information about the specific issue that led to the transaction being declined, helping the merchant and the customer troubleshoot the problem. While the decline reason field provides valuable information, it may not cover all possible reasons for a decline, such as technical issues or unforeseen circumstances. {% admonition type="warning" %} New decline reasons may be added in the future, and not all decline reasons are currently documented. Review this documentation regularly to ensure accuracy. {% /admonition %} {% admonition type="warning" %} Exercise caution when communicating decline reasons to your customers, as some may not be relevant or may cause confusion. {% /admonition %} - `ACCOUNT_INACTIVE` - Balance related to the transaction is not active. Ensure that all outstanding actions have been completed before using the card, as this may help avoid potential issues or declines - `ACCOUNT_SUSPENDED` - The transaction has been declined pending further compliance checks. It may have been flagged for potential sanctions issues - `ATM_PIN_CHANGE_NOT_ALLOWED` - PIN change via ATM terminal is not allowed - `BLOCKED_COUNTRY` - Transactions were made in unsupported countries. Check this [link](https://wise.com/help/articles/2935771/where-can-i-use-my-wise-card) to see if the country is included in the list of supported nations. It is possible for a merchant to be based in a supported country and have an address registered in a blocked country, albeit infrequently - `BLOCKED_SUBSCRIPTION` - The system cannot facilitate this transaction as the customer has opted out of recurring payments with this merchant - `CARD_EXPIRED` - The card provided has reached its expiration date, making it invalid for this transaction - `CARD_FROZEN` - The customer or the customer service team has put this card on a temporary hold. If the card has not been frozen by the customer, it may be worth investigating further. To resume spending, advise the customer to unfreeze the card - `CARD_INACTIVE` - The card is either not active or has not been received by the customer, so the transaction cannot proceed - `CARD_BLOCKED` - The card has been blocked and cannot be used anymore - `CARD_PARTNER_SUSPENDED` - The internal team has deactivated the account for compliance reasons related to AML, fraud, or EDD. Contact the team if this is believed to be an error - `CHIP_PIN_ENTRY_TRIES_EXCEEDED` - The PIN is restricted on the chip of the card due to excessive incorrect entries. The blocked PIN can be unlocked at an ATM using specific steps that vary depending on the machine and country, such as PIN management or PIN operations followed by unblocking the PIN - `CONNECTION_ISSUE` - A connection problem occurred during the transaction - `CONTACTLESS_PIN_ENTRY_REQUIRED` - Contactless payment systems sometimes require a PIN for authentication purposes to protect users' accounts from potential fraud or tampering. In Europe, contactless payment transactions that follow one after the other require PIN verification as an additional security measure - `CREDIT_TRANSACTIONS_NOT_SUPPORTED` - Credit is not supported for this specific transaction. Review the [Acceptable Use Policy](https://wise.com/gb/legal/acceptable-use-policy-eea) for further information - `CUMULATIVE_LIMIT_EXCEEDED` - In certain jurisdictions, there are restrictions on the amount that can be spent. Refer to [spending limits](https://wise.com/help/articles/2899986/what-are-my-spending-limits) for further details - `DECLINED_ADVICE` - There is a problem with the message from the processor, so it might not be accepted because it could be incomplete or unsafe. This does not indicate a problem with the card. Advise the customer that there was a technical issue with the payment and to try again later - `INCORRECT_CVV` - The customer entered the wrong security code. Advise the customer to check their card details and try again. If the saved card details are correct, they should remove their card details from the merchant's website and add them back again - `INCORRECT_EXPIRY_DATE` - The customer entered the wrong expiration date for their card. If the saved card details are correct, they should remove their card details from the merchant's website and add them back again - `INCORRECT_PIN` - The customer entered their PIN incorrectly. Advise the customer to check their PIN and try again. If the PIN is correct and still fails, suggest resetting the PIN - `INSUFFICIENT_FUNDS` - The customer does not have enough money in their account to make the payment. Advise the customer to add money to their account and try again. In most cases, this will resolve the issue - `INVALID_3DS_UCAF` - The 3D Secure checks failed during the transaction. The customer should try again and request authentication - `INCORRECT_ARQC` - ARQC (Authorization Request Cryptogram) is a cryptogram generated by the card during a transaction, which is validated on the server side. If incorrect, it could indicate a faulty card, a fraudulent attack, or an issue with the POS terminal - `INCORRECT_ICVV` - ICVV (Integrated Circuit Card Verification Value) is a security feature used to validate the authenticity of a card during chip-based transactions. There were problems reading the chip on the card, which may indicate an issue with the card's chip, the terminal, or the transaction process. Wait and try again - `INVALID_MERCHANT` - Transaction from a specific merchant is declined by scheme. The merchant should clarify the exact cause with the scheme - `INVALID_TRANSACTION` - Certain types of transactions are not supported. The customer should ask the merchant to use a different payment method or try a different merchant - `MANDATE_DCC_NON_SUPPORTED_FOR_CARD_COUNTRY` - The transaction was declined because the system does not support conversions for Brazilian cards when BRL is involved. BRL will not be automatically exchanged to other currencies. If the customer wants to continue with the payment, they need to change the currency - `MANDATE_LOCAL_CASH_WITHDRAWAL_NOT_ALLOWED` - ATM withdrawal services are not provided in the country where the transaction is taking place - `NON_SUPPORTED_CURRENCY` - The currency in this transaction is not supported - `NON_SUPPORTED_MCC_FOR_COUNTRY` - Transactions in this category are not supported for customers in the country of purchase. Consider using an alternative payment method or changing merchant - `PAYMENT_METHOD_DAILY_LIMIT_EXCEEDED` - The customer has reached the daily spending limit for the card or their profile. Advise if they would like to update [card](/api-reference/spend-limits/spendlimitscardupdate) or [profile](/api-reference/spend-limits/spendlimitsprofileupdate) limit - `PAYMENT_METHOD_LIFETIME_LIMIT_EXCEEDED` - The customer has reached the lifetime spending limit. Advise if they would like to [increase](/api-reference/spend-limits/spendlimitscardupdate) their lifetime limit - `PAYMENT_METHOD_MONTHLY_LIMIT_EXCEEDED` - The customer has reached the monthly spending limit for the card or their profile. Advise if they would like to update [card](/api-reference/spend-limits/spendlimitscardupdate) or [profile](/api-reference/spend-limits/spendlimitsprofileupdate) limit - `PAYMENT_METHOD_NOT_ALLOWED` - This payment type has been disabled. Advise if they would like to [enable](/api-reference/card/cardpermissionsupdate) the payment type - `PAYMENT_METHOD_TRANSACTION_LIMIT_EXCEEDED` - The customer has exceeded the transaction limit for the card. Advise if they would like to update their [card](/api-reference/spend-limits/spendlimitscardupdate) limit - `PIN_ENTRY_TRIES_EXCEEDED` - The customer has reached the maximum number of allowed online PIN entry attempts. Consider implementing a [reset PIN](/api-reference/card/cardpincountreset) feature within the app to help the customer regain access to their card - `PRE_ACTIVATED_CARD_PIN_ENTRY_REQUIRED` - The customer has attempted to make a contactless payment at a POS or ATM, but their card has not been activated for chip and PIN transactions. To modify the card activation strategy for all cards, contact the implementation manager - `PROCESSING_ERROR` - The system is currently experiencing technical difficulties. Advise the customer to try again after a brief period - `RESTRICTED_MODE` - Although rare, restricted mode can occur. Advise the customer to replace their card promptly as the system should have already informed them. In this mode, more secure payment methods like chip and PIN, contactless, mobile wallets, and online payments with 3DS are allowed, while less secure methods like magnetic stripe and online payments without 3DS are not permitted - `REVERSAL_NOT_MATCHING_AUTH_CURRENCY` - The merchant has issued a reversal instruction for a different currency than what was originally requested during the authorization process - `SCA_SOFT_DECLINE` - The transaction cannot proceed due to SCA regulations. Suggest the customer contact the merchant and use a more secure authentication method such as 3DS. For example, the customer can try chip and PIN, or a mobile wallet like Apple Pay or Google Pay - `SCHEME_BLOCKED_TRANSACTION` - This transaction has been flagged by the scheme and cannot be processed - `SECURITY_CVM_FAILURE` - The system has detected that the POS terminal was misconfigured and failed security checks. Suggest the customer use an alternative payment method like contactless or mobile wallets, or recommend asking the merchant to accept a signature instead - `SECURITY_MAGSTRIPE_SECURE_ELEMENTS_INCORRECT_OR_MISSING` - The merchant has entered the wrong type of purchase. Advise the customer to contact the merchant and ask them to correct this issue - `SECURITY_PIN_ENTRY_REQUIRED` - To proceed with this transaction, the customer is required to enter their PIN - `SUSPECTED_FRAUD` - This transaction has been labeled as high-risk by Wise - `SUSPECTED_FRAUD_AML` - This transaction has been flagged as high-risk based on AML compliance protocols. This reason cannot be disclosed to end customers - `SUSPECTED_FRAUD_COMPLIANCE` - The compliance system has flagged this transaction as high-risk. This reason cannot be disclosed to end customers - `SUSPECTED_FRAUD_CORE_FRAUD` - This transaction has been blocked based on fraud policies and procedures - `SUSPECTED_FRAUD_SANCTIONS` - This transaction has been flagged as high-risk based on sanctions list analysis. This reason cannot be disclosed to end customers. This classification is final and cannot be appealed - `SUSPECTED_FRAUD_SOFT_DECLINE` - This e-commerce transaction cannot be processed due to high risk factors. The merchant must complete 3DS before the transaction can be approved - `TRANSACTION_TYPE_NOT_SUPPORTED` - There are restrictions on this type of transaction, and sometimes the scheme will not allow it. Check if [spend control](/api-reference/spend-controls) is set up to block this transaction - `UNEXPECTED_ERROR` - There may have been a communication error between the merchant's system and the server, but the POS system may have already notified the user of this issue Detailed decline reasons {% #card-transaction-detailed-decline-reasons .title-3 .m-t-5 %} Detailed decline reasons provide secondary level information for certain decline reasons, adding more context to transaction failures. Please be aware that new detailed decline reasons may be added in the future, and not all reasons are currently documented. Therefore, it is important to exercise caution and regularly review the documentation to ensure accuracy. {% admonition type="warning" %} Please exercise caution when communicating reasons to your customers, as some may not be relevant or may cause confusion. If you have any questions or concerns, we are here to assist you. {% /admonition %} - `INSUFFICIENT_FUNDS_FOR_BLOCKED_SMART_CONVERSION` - Transaction was declined due to insufficient balance in transaction currency when smart conversion feature is disabled (e.g. BRL cards). The customer needs to convert their funds to the transaction currency and try again. - `INSUFFICIENT_FUNDS_FOR_SPECIFIC_CURRENCY_RESERVATION` - The transaction will be declined with this reason if the customer's card is issued in a region subject to smart conversion limitations, and the transaction currency is the limited currency but the customer doesn't hold enough of that currency. Other currencies won't be automatically converted to the limited currency. The customer needs to convert their funds to the transaction currency before retrying the payment. - `SUSPECTED_FRAUD_NO_BALANCE` - The customer might be abusing merchants by saving a card without having any balance to cover upcoming charges from them. The customer will need to top up their account to cover any charges from the merchant at a later date before re-attempting the transaction. - `RESET_YOUR_PIN_AT_ATM` - There's a problem with how Chip was read and we had to decline the transaction. The customer will need to reset their PIN at an ATM. - `INCORRECT_CVV2` - Invalid CVV2 was provided. The customer needs to check their saved card details and if they're correct, they should remove and add their card details to the merchant's website again. If this doesn't help, they could try to use their card at another merchant's website. If the same issue happens, they'll need to order a new card. - `SCA_SOFT_DECLINE_CONTACTLESS` - Contactless transaction could not be approved due to SCA regulations. The customer should perform at least one PIN transaction or use an ATM to reset PIN. - `SUSPECTED_FRAUD_REVIEW_ACTIVITY` - We couldn't confirm all transactions in the customer's activity were done by them, so we froze their card. The customer should review recent transactions and unfreeze the card. - `INVALID_TRANSACTION_TYPE_FINAL` - This decline reason is used for unmapped processor or network error codes, indicating an external system issue or unclassified response. The decision authority on the transaction information identifies a SCHEME decline, which may relate to card usage in unsupported countries. The customer will need to use an alternative payment method to complete this transaction. - `INVALID_TRANSACTION_TYPE_CONTACTLESS_MAGSTRIPE` - The POS terminal used a deprecated and not secure way to transmit card data. The customer will need to use another POS machine or try another payment method (Chip and PIN or Mobile Wallet). - `INVALID_TRANSACTION_TYPE_FALLBACK` - The chip couldn't be read due to a technical issue which resulted in the transaction "falling back" to magnetic stripe. As damaging the chip (so it would fall back to stripe) is a common way of fraud, these types of transactions are often deemed risky and being blocked. The customer will need to: - Try again or try a different terminal / ATM if it still doesn't work - Use another payment method, e.g. Contactless - Use another card - If the issue persists with multiple terminals, they'll need to replace their card as it may be damaged - `CONTACTLESS_DISABLED` - `POS_CONTACTLESS` permission (contactless payments) is disabled. The customer will need to enable the permission to allow contactless transactions. - `ECOM_DISABLED` - `ECOM` permission (online payments) is disabled. The customer will need to enable the permission to allow e-commerce transactions. - `CHIP_DISABLED` - `POS_CHIP` permission (Chip transactions) is disabled. The customer will need to enable the permission to allow Chip transactions. - `MAGSTRIPE_DISABLED` - `POS_MAGSTRIPE` permission (magnetic stripe transactions) is disabled. The customer will need to enable the permission to allow magnetic stripe transactions. - `WALLET_DISABLED` - `MOBILE_WALLETS` permission is disabled. The customer will need to enable the permission to allow mobile wallet transactions. - `PROFILE_GENERAL_DAILY_LIMIT_EXCEEDED_CHANGEABLE` - The customer has reached their daily total account limit (profile-level). The customer will need to edit the limit. - `PROFILE_GENERAL_MONTHLY_LIMIT_EXCEEDED_CHANGEABLE` - The customer has gone over their monthly total account limit (profile-level). The customer will need to edit the limit. - `CARD_GENERAL_DAILY_LIMIT_EXCEEDED_CHANGEABLE` - The customer has reached their daily limit for this card (card-level). The customer will need to edit the limit. - `CARD_GENERAL_MONTHLY_LIMIT_EXCEEDED_CHANGEABLE` - The customer has gone over the monthly limit for this card (card-level). The customer will need to edit the limit. - `PAYMENT_METHOD_MAX_MONTHLY_LIMIT_EXCEEDED` - The card's maximum non-changeable monthly spending limit has been reached. The customer will need to wait until the start of the next calendar month to perform transactions again. - `UNKNOWN` - This decline reason is used when the processor or network returns an error code that is not mapped to any of our specific detailed decline reasons. This can be caused by various external system issues or unclassified processor responses. ### Get card transaction - [GET /v4/spend/profiles/{profileId}/cards/transactions/{transactionId}](https://docs.wise.com/api-reference/card-transaction/cardtransactionget.md): Retrieve a card transaction by its ID. Use in conjunction with the V2.1.0 card transaction state change webhook. {% admonition type="warning" %} Only transactions created in the past 90 days can be accessed. A 422 error code will be returned otherwise. {% /admonition %} When a refund happens, a separate transaction will be added with a REFUND transaction type. ### List card transactions - [GET /v4/spend/profiles/{profileId}/cards/{cardToken}/transactions](https://docs.wise.com/api-reference/card-transaction/cardtransactionlist.md): Retrieve a list of card transactions for a specific card. Transactions are ordered by transaction ID in descending order. Use in conjunction with the V2.1.0 card transaction state change webhook. {% admonition type="warning" %} Only transactions created in the past 90 days can be accessed. A 422 error code will be returned otherwise. {% /admonition %} The debits and credits fields are not included in list responses. Use the Get card transaction endpoint to retrieve these fields. ### Get card transaction (V3) (deprecated) - [GET /v3/spend/profiles/{profileId}/cards/transactions/{transactionId}](https://docs.wise.com/api-reference/card-transaction/cardtransactiongetv3.md): {% admonition type="warning" %} This endpoint is deprecated. Use the V4 Get card transaction endpoint instead. {% /admonition %} Retrieve a card transaction by its ID. Use in conjunction with the V2.0.0 card transaction state change webhook. When a refund happens, a separate transaction will be added with a REFUND transaction type. ## Claim Account Allow a customer to take ownership of an account [created on their behalf](/api-reference/user/usercreate). Generate a short-lived `claim_account_code` and use it when [redirecting the customer to Wise](/guides/product/kyc/wise-kyc/redirect-to-wise/claim-account) to finalize their account setup. ### Generate a claim account code - [POST /v1/user/claim-account](https://docs.wise.com/api-reference/claim-account/claimaccountcreate.md): Generate a short-lived claim_account_code that allows a customer to take ownership of an account. Use the code when redirecting the customer to Wise to finalize their account setup. ## Comparison The comparison API can be used to request price and speed information about various money transfer providers. This includes not only Wise but other providers in the market. Price Estimation {% #comparison-price-estimation .title-3 .m-t-5 %} The quotes (price and speed) provided by this API are based off of real quotes collected from 3rd party websites. We collect both the advertised exchange rate and fee for each provider for various amounts. When a comparison is requested, we calculate the markup percentage of the collected exchange rate on the mid-market rate at the time of collection. We then apply this markup to the current mid-market rate to provide a realistic estimate of what each provider offers. We collect data for all providers around once per hour to ensure we provide as accurate and up-to-date information as possible. Note: Today, we only provide estimations for FX transactions with a Bank Transfer pay-in and pay-out option. This is important to stress as many providers offer significantly different fees and exchange rates when used debit/credit card, cash etc. For more details on the data collection process please see the following page: [https://wise.com/gb/compare/disclaimer](https://wise.com/gb/compare/disclaimer) If you have questions or suspect any data to be inaccurate or incomplete please contact us at: [comparison@wise.com](mailto:comparison@wise.com) Delivery Estimation {% #comparison-delivery-estimation .title-3 .m-t-5 %} Similar to price, we collect speed data for most (if not all) providers which we have price information for. Many providers display speed estimates to their customers in a number of different ways. Some examples: - "The transfer should be complete within 2-5 days" - "The money should arrive in your account within 48 hours" - "Should arrive by 26th Aug" - "Could take up to 4 working days" The below API intends to model these in a consistent format by providing a minimum and maximum range for all delivery estimations. An estimate that states "up to X" will have "max" set to a duration but "min" as null; "from X" will have "min" set to a duration and "max" as null. Finally, for those providers who offer a specific, point in time estimation (like Wise), the API will surface a duration where "min" and "max" are equal. Quotes structure {% #comparison-quotes-structure .title-3 .m-t-5 %} In order to provide the most flexible and accurate data for clients, we surface a denormalized list of quotes per provider where each quote represents a unique collection of comparison "dimensions". A single given provider may expose multiple quotes for the same currency route. The most common example is where a provider offers different pricing for two different countries which use the same currency, e.g.: Provider X: - GBP EUR 1000 [GB -> ES] fee: 10, rate: 1.5 - GBP EUR 1000 [GB -> DE] fee: 8, rate: 1.5 - GBP EUR 1000 [GB -> FR] fee: 10, rate: 1.35 The same principle applies for speed, i.e. a provider may have different speed estimates for different target countries. Hence, we expose these as discrete quotes, where a quote is a unique combination of route, country, speed and price factors. A client may choose to reduce this set of quotes down to a single or several quotes in order to display a relevant quote to a given user. An example where we take the cheapest quote for a given currency route (and also surface the target country) can be seen at the below link: [https://wise.com/gb/compare/?sourceCurrency=GBP&targetCurrency=EUR&sendAmount=1000](https://wise.com/gb/compare/?sourceCurrency=GBP&targetCurrency=EUR&sendAmount=1000) ### Request a comparison quote - [GET /v4/comparisons](https://docs.wise.com/api-reference/comparison/comparisonget.md): Request price and speed comparison data for money transfer providers on a given currency route. You must provide either sendAmount or recipientGetsAmount (but not both). ### Request a comparison quote (V3) (deprecated) - [GET /v3/comparisons](https://docs.wise.com/api-reference/comparison/comparisongetv3.md): {% admonition type="warning" name="Deprecated" %} This endpoint is deprecated. Use the V4 comparison endpoint instead. {% /admonition %} Request price and speed comparison data for money transfer providers on a given currency route. ## Contact Find discoverable Wise profiles and add them to your recipient list using an identifier — such as a Wisetag, email, or phone number — without needing bank details. Creating a transfer with a contact {% .title-3 .m-t-5 %} 1. [Create a Quote](/api-reference/quote/quotecreate), passing `contactId` instead of `targetAccount` in the request body. 2. Extract the `targetAccount` value from the Quote response — Wise resolves the contact into a recipient account. 3. [Create a Transfer](/api-reference/transfer/transfercreate) using the `targetAccount` from the Quote response. ### Create a contact from an identifier - [POST /v2/profiles/{profileId}/contacts](https://docs.wise.com/api-reference/contact/contactcreate.md): Finds an existing discoverable Wise profile and adds it to your recipient list. The recipient is found by an identifier — such as a Wisetag, email, or phone number — without needing bank details. Use the contactId from the response to create a transfer. ## Currencies Retrieve the list of currencies supported for transfers, including currency codes and display names. ### Get all currencies allowed for transfers - [GET /v1/currencies](https://docs.wise.com/api-reference/currencies/currenciesget.md): Returns all currencies available for creating transfers. Currency names are returned in English by default — pass an Accept-Language header to receive localized names. ## Delivery Estimate Get the estimated delivery time for a transfer, showing when funds are expected to arrive in the recipient's bank account. ### Get the delivery estimate for a transfer - [GET /v1/delivery-estimates/{transferId}](https://docs.wise.com/api-reference/delivery-estimate/deliveryestimateget.md): Get the live delivery estimate for a transfer by the transfer ID. The delivery estimate is the time at which we currently expect the transfer to arrive in the beneficiary's bank account. This is not a guaranteed time but we are working hard to make these estimates as accurate as possible. ## Digital Wallet These APIs provide encrypted cardholder information needed to implement push provisioning (Apple Pay, Google Pay) in your own mobile app. ### List payment tokens for a card - [POST /v3/spend/profiles/{profileId}/cards/{cardToken}/payment-tokens](https://docs.wise.com/api-reference/digital-wallet/pushprovisioningpaymenttokenslist.md): You have the option to obtain the payment tokens associated with a card, which can assist in determining if it's already linked to a specific wallet. Note that the payment token status associated with the card may not be accurate (for example, after a phone factory reset). Therefore, it's advisable to consistently check the wallet instance for the most up-to-date token status. ### Manual provisioning payment token activation - [POST /v3/spend/profiles/{profileId}/cards/{cardToken}/payment-tokens/{paymentTokenUniqueReference}/activation](https://docs.wise.com/api-reference/digital-wallet/digitalwalletactivatepaymenttoken.md): This endpoint activates the payment token for a card that has been manually added to a wallet provider. Please read this guide before implementing this API. {% admonition type="warning" %} This API is not available for sandbox testing. {% /admonition %} ### Push provisioning for Google Pay - [POST /twcard-data/v1/push-provisioning/encrypted-payload/google-pay](https://docs.wise.com/api-reference/digital-wallet/pushprovisioninggooglepayget.md): Returns encrypted cardholder information and other metadata needed for Google Pay push provisioning. {% admonition type="warning" %} This API is not available for sandbox testing. {% /admonition %} ### Push Provisioning for Apple Pay - [POST /twcard-data/v1/push-provisioning/encrypted-payload/apple-pay](https://docs.wise.com/api-reference/digital-wallet/pushprovisioningapplepayget.md): Returns encrypted cardholder information and other metadata needed for Apple Pay push provisioning. {% admonition type="warning" %} This API is not available for sandbox testing. {% /admonition %} ## Direct Debit Account Register and retrieve external bank accounts used to fund batch transfers via ACH (USD) or EFT (CAD) direct debit. ### Create a direct debit account - [POST /v1/profiles/{profileId}/direct-debit-accounts](https://docs.wise.com/api-reference/direct-debit-account/directdebitaccountcreate.md): Register a new external bank account for funding batch transfers via direct debit. ### Retrieve all direct debit accounts - [GET /v1/profiles/{profileId}/direct-debit-accounts](https://docs.wise.com/api-reference/direct-debit-account/directdebitaccountget.md): Get a list of your direct debit accounts. Use the type and currency query parameters to filter accounts. ## Disputes Raise and manage card transaction disputes, including submission via Dynamic Flow or direct API, file uploads, and dispute lifecycle tracking. For implementation details, see: - [Disputes via Dynamic Flow](/guides/product/issue-cards/card-disputes-dynamic-flow) — build a dispute UI using the Dynamic Flow framework - [Disputes via API](/guides/product/issue-cards/card-disputes-api) — submit disputes directly, with per-reason request body details - [Dispute management](/guides/product/issue-cards/card-disputes-management) — track and withdraw disputes Dispute sub-statuses {% #dispute-sub-status .title-3 .m-t-5 %} The possible `subStatus` values are: - `SUBMITTED` — Initial status - `IN_REVIEW` — The dispute is under review or requires additional information - `REFUNDED` — The refund has been processed - `REJECTED` — The dispute is invalid - `WITHDRAWN` — The customer has withdrawn the dispute - `CONFIRMED` — The dispute has been reviewed but a refund is not applicable - `REFUND_IN_PROGRESS` — A refund is being processed - `ATTEMPTING_RECOVERY` — A chargeback request has been submitted - `RECOVERY_UNSUCCESSFUL` — The chargeback attempt was unsuccessful {% admonition type="warning" %} The status transition diagram may undergo modifications in the future and only covers regular pathways. {% /admonition %} {% img src="/images/diagrams/dispute-status-flow.png" alt="Dispute statuses transition diagram" /%} ### Dispute dynamic flow entry point - [POST /v3/spend/profiles/{profileId}/dispute-form/flows/step/{scheme}/{reason}](https://docs.wise.com/api-reference/disputes/disputedynamicflowstep.md): Retrieves the JSON for initiating the dispute flow. Use this endpoint with Wise's Dynamic Flow framework. The JSON response must be passed into the Dynamic Flow framework, which handles the multi-step dispute submission including the generation of subsequent pages and the creation of the dispute. Setting up the API You will need to implement a GET API with the following format: GET https://{{yourApiUrl}}/v3/spend/profiles/{{profileId}}/dispute-form/flows/step/{{scheme}}/{{reason}}?transactionId={{transactionId}} This API should forward the call to: POST https://{{wiseUrl}}/v3/spend/profiles/{{profileId}}/dispute-form/flows/step/{{scheme}}/{{reason}}?transactionId={{transactionId}} This is required as the dynamic flow returned by Wise will automatically be configured to call your GET API. Use baseUrl or fetcher as part of the dynamic flow setup to redirect the Dynamic Flow JavaScript library to your domain. For a full integration guide, including example backend implementation and styling, see Disputes via Dynamic Flow. ### Retrieve dispute reasons - [GET /v3/spend/profiles/{profileId}/dispute-form/reasons](https://docs.wise.com/api-reference/disputes/disputereasonsget.md): Retrieves the list of possible reasons for submitting a dispute. If a reason code has subOptions, those should be used as the reason code when submitting disputes. ### Submit dispute - [POST /v3/spend/profiles/{profileId}/dispute-form/flows/{scheme}/{reason}](https://docs.wise.com/api-reference/disputes/disputesubmit.md): Submit a dispute for a card transaction. The request body structure varies per dispute reason code. All reasons share a common structure with transaction, form, disclaimer, and files objects, but the fields within form and files differ per reason. For per-reason request body details, see the disputes via API guide. ### Upload dispute file - [POST /v4/spend/profiles/{profileId}/dispute-form/file](https://docs.wise.com/api-reference/disputes/disputefileupload.md): Upload a file for use in a dispute submission. Use the returned file ID in the files object when submitting a dispute. A dispute referencing the returned file ID must be submitted no later than two hours after the file upload, otherwise the file will expire and must be re-uploaded. ### List disputes - [GET /v3/spend/profiles/{profileId}/disputes](https://docs.wise.com/api-reference/disputes/disputelist.md): List disputes for a profile with optional filters. ### Get dispute - [GET /v3/spend/profiles/{profileId}/disputes/{disputeId}](https://docs.wise.com/api-reference/disputes/disputeget.md): Retrieve a dispute by its ID. ### Withdraw dispute - [PUT /v3/spend/profiles/{profileId}/disputes/{disputeId}/status](https://docs.wise.com/api-reference/disputes/disputewithdraw.md): Withdraw a dispute by setting its status to CLOSED. You can only withdraw a dispute if canWithdraw is true on the dispute resource. ### Upload dispute file (v3) (deprecated) - [POST /v3/spend/profiles/{profileId}/dispute-form/file](https://docs.wise.com/api-reference/disputes/disputefileuploadv3.md): {% admonition type="warning" %} This endpoint is deprecated. Use the v4 upload dispute file endpoint instead. {% /admonition %} Submit a file for disputes. This API is not available for sandbox testing. Use the fileId in the response for the dispute submission. NB: A dispute referencing the returned fileId must be submitted no later than two hours after the file submission, otherwise the file will expire and must be re-submitted. ## FaceTec Wise leverages [FaceTec's](https://www.facetec.com/) facial biometric technology for authentication. Use this endpoint to retrieve the public key needed for exporting 3D FaceMaps. ### Get FaceTec public key - [GET /v1/facetec/public-key](https://docs.wise.com/api-reference/facetec/facetecpublickeyget.md): Retrieve Wise's FaceTec public key to be used when exporting 3D FaceMap from your FaceTec host to Wise. The exported FaceMap can be used to Enrol FaceMap. ## JOSE Wise uses the [JOSE framework](https://jose.readthedocs.io/en/latest/) to accept and respond with signed and encrypted payloads. These endpoints allow you to manage keys and test your signing and encryption implementation. For more information, please speak with your Implementation team. ### Get Wise public signing key - [GET /v1/auth/jose/response/public-keys](https://docs.wise.com/api-reference/jose/joseresponsepublickeysget.md): Returns a public key issued by Wise for verifying signed HTTP responses and for encrypting payloads. For both signature verification and payload encryption, the process involves storing this public key after retrieval. In both cases, the stored public key should be used without calling this endpoint. If verification of the signed request fails or you receive an encryption error, call this API once to issue a fresh key from Wise and then try verification one more time. {% admonition type="warning" %} This endpoint requires a client credentials token, not a user level access token. Make sure you use your client details to fetch a valid client credentials token before performing this call. {% /admonition %} ### Add a new client public key - [POST /v1/auth/jose/request/public-keys](https://docs.wise.com/api-reference/jose/joserequestpublickeyscreate.md): Upload a client public key for request payload signing or response payload encryption. {% admonition type="warning" %} This endpoint requires a client credentials token, not a user level access token. Make sure you use your client details to fetch a valid client credentials token before performing this call. {% /admonition %} ### Playground JWS - [POST /v1/auth/jose/playground/jws](https://docs.wise.com/api-reference/jose/joseplaygroundjws.md): Send test signed HTTP requests and receive signed responses. Signing is mandatory for this endpoint — any message that is not a JSON Web Signature (JWS) will be rejected. ### Playground JWE for GET requests - [GET /v1/auth/jose/playground/jwe](https://docs.wise.com/api-reference/jose/joseplaygroundjweget.md): Send test HTTP GET requests and receive encrypted responses. ### Playground JWE for POST requests - [POST /v1/auth/jose/playground/jwe](https://docs.wise.com/api-reference/jose/joseplaygroundjwepost.md): Send test encrypted HTTP requests and receive encrypted responses. Encryption is mandatory for this endpoint — any message that is not in JSON Web Encryption (JWE) format will be rejected. ### Playground JWE for direct encryption - [POST /v1/auth/jose/playground/jwe-direct-encryption](https://docs.wise.com/api-reference/jose/joseplaygroundjwedirectencryption.md): Send encrypted HTTP requests for testing purposes and receive responses encrypted with the original content encryption key. Encryption is mandatory for this endpoint — any message that is not in JSON Web Encryption (JWE) format will be rejected. ### Playground JWS+JWE - [POST /v1/auth/jose/playground/jwsjwe](https://docs.wise.com/api-reference/jose/joseplaygroundjwsjwe.md): Send test signed and encrypted HTTP requests and receive signed and encrypted responses. Both signing and encryption are mandatory for this endpoint. The request must be a JSON Web Signature (JWS) wrapped in JSON Web Encryption (JWE) — any message that does not follow this format will be rejected. The flow combines both JWS and JWE: 1. Request: Sign payload (JWS) → Encrypt signed JWT (JWE) → Send to Wise 2. Response: Receive encrypted response → Decrypt (JWE) → Verify signature (JWS) {% admonition type="warning" name="" %} Currently, the Wise API returns a generic 500 Internal Server Error for decryption failures across endpoints using JWE and JWS+JWE. For example, an invalid key can cause a decryption failure. Our team is currently planning improvements for these types of error messages to make them more specific and clear. Thank you for your patience. {% /admonition %} ## KYC Review KYC Review API provides endpoints to view, update and submit information related to the KYC flow. There are two ways to collect KYC requirements from your customers: - **Hosted KYC** — redirect your customer to a Wise-hosted UI that guides them through the process. - **API submission** — use the [KYC Requirement Submit](/api-reference/kyc-review/kycreviewrequirementsubmit) endpoint to submit requirements directly. This is only available for requirement types where `apiCollectionSupported` is `true`. Please refer to our [Hosted KYC guide](/guides/product/kyc/wise-kyc/hosted-kyc) for more information on the general use of the endpoints included below. ### Create a KYC Review - [POST /v1/profiles/{profileId}/kyc-reviews](https://docs.wise.com/api-reference/kyc-review/kycreviewcreate.md): Creates a KYC Review for a specific customer action. ### Get all KYC Reviews for a profile - [GET /v1/profiles/{profileId}/kyc-reviews](https://docs.wise.com/api-reference/kyc-review/kycreviewlist.md): Retrieves a list of all active KYC Reviews for a given profile. ### Update KYC Review to get a Hosted KYC link - [PATCH /v1/profiles/{profileId}/kyc-reviews/{kycReviewId}](https://docs.wise.com/api-reference/kyc-review/kycreviewredirecturlupdate.md): Updates the KYC Review with a redirect URL. Returns the KYC Review object with a link field containing a URL where the end customer needs to be directed in order to complete the Hosted KYC flow. Once the Hosted KYC flow is completed by the end customer, they will be redirected to the redirectUrl provided in this API call. During the redirection, the redirectUrl will be appended with query parameters: status=success, status=failed, or status=closed. ### Get KYC Review by ID - [GET /v2/profiles/{profileId}/kyc-reviews/{kycReviewId}](https://docs.wise.com/api-reference/kyc-review/kycreviewget.md): Retrieves a single KYC Review by ID for a profile. ### Submit a KYC Requirement - [POST /v2/profiles/{profileId}/kyc-requirements/{requirementKey}](https://docs.wise.com/api-reference/kyc-review/kycreviewrequirementsubmit.md): {% admonition type="warning" %} This functionality is in a closed BETA. {% /admonition %} Submit a KYC requirement for a KYC Review. - A KYC requirement can only be submitted if the KYC Review status is WAITING_CUSTOMER_INPUT. - A KYC requirement should only be submitted if its state is NOT_PROVIDED and apiCollectionSupported is true. See the KYC requirement types guide for the full list of supported requirement types, submission data structures, and accepted values. ### Get KYC Review by ID (V1) (deprecated) - [GET /v1/profiles/{profileId}/kyc-reviews/{kycReviewId}](https://docs.wise.com/api-reference/kyc-review/kycreviewgetv1.md): {% admonition type="warning" %} This endpoint is deprecated. Use Get KYC Review by ID (V2) instead. {% /admonition %} Retrieves a single KYC Review by ID for a profile. ## Multi Currency Account The Wise multi-currency account (MCA) enables users to hold, convert, and fund transfers (single or batches) with balances in up to 56 currencies. Of the 50+ currency balances supported, 10+ come with local account details. Please refer to our [multi-currency account guide](/guides/product/accounts/managing-accounts) for more information on the general use of the endpoints included below. Please see the [Balances APIs](/api-reference/balance) for more details. ### Retrieve available currencies - [GET /v2/borderless-accounts-configuration/profiles/{profileId}/available-currencies](https://docs.wise.com/api-reference/multi-currency-account/mcaavailablecurrenciesget.md): Lists all currencies that are available for balance accounts. This includes those that can have funds added from external accounts, as well as those that a balance can be held in. ### Retrieve payin currencies - [GET /v2/borderless-accounts-configuration/profiles/{profileId}/payin-currencies](https://docs.wise.com/api-reference/multi-currency-account/mcapayincurrenciesget.md): Lists all currencies available for balance accounts that also support bank account details. You can use this list to create a balance account for the currency included and then subsequently create bank account details. ### Retrieve multi currency account for a profile - [GET /v4/profiles/{profileId}/multi-currency-account](https://docs.wise.com/api-reference/multi-currency-account/mcaget.md): Returns the multi-currency account details for the specified profile. If the user does not yet have a multi-currency account, a 404 Not Found will be returned. ### Retrieve multi currency account eligibility - [GET /v4/multi-currency-account/eligibility](https://docs.wise.com/api-reference/multi-currency-account/mcaeligibilityget.md): Checks eligibility for a multi-currency account for either a specific profile or for a location. Customers in some countries and states/provinces may not be eligible for a multi currency account. To check a profile, pass the profileId as a query parameter. To check a specific location, pass the country using 2-letter ISO 3166 codes. If the country is US, a valid 2-letter state parameter must also be passed. - Example (France): /v4/multi-currency-account/eligibility?country=FR - Example (USA, California): /v4/multi-currency-account/eligibility?country=US&state=CA ## OAuth Token Exchange client credentials or authorisation grants for OAuth 2.0 access tokens. All grant types use `POST /oauth/token` with basic authentication (your `client_id` and `client_secret`). Depending on the grant type, this endpoint issues either a **client credentials token** or a **user token**. Client credentials token {% .title-3 .m-t-5 %} An application-level token for requests that aren't tied to a specific Wise user, such as generating un-authenticated quotes and subscribing to application webhooks. Valid for 12 hours. - `client_credentials` — the only grant type for this token. User token {% .title-3 .m-t-5 %} A token for making API calls on behalf of a specific Wise user, such as creating transfers and managing balances. Access tokens are valid for 12 hours and can be refreshed using a refresh token. Grant types: - `registration_code` — for partners that create Wise users via API. Exchanges a registration code for a user access token and refresh token. - `authorization_code` — for partners using the OAuth redirect flow. Exchanges an authorisation code for a user access token and refresh token. - `refresh_token` — obtain a new user access token without requiring the user to re-authorise. Managing token expiration {% #managing-token-expiration .title-3 .m-t-5 %} Access tokens are valid for 12 hours. You can request a new access token whenever it's close to expiring — there is no need to wait for the actual expiration to happen first. Depending on how your application uses the Wise Platform API, requesting a new access token before attempting a series of API calls on behalf of an individual user will avoid issues with expired access tokens. ### Create an OAuth token - [POST /oauth/token](https://docs.wise.com/api-reference/oauth-token/oauthtokencreate.md): Exchange credentials or authorisation grants for an OAuth 2.0 access token. The grant_type field determines which parameters are required and which response fields are returned. See managing token expiration for guidance on refreshing tokens before they expire. ## One Time Token {% admonition type="warning" %} These endpoints are deprecated. Please refer to [Strong Customer Authentication](/api-reference/strong-customer-authentication) to integrate with SCA. {% /admonition %} Represents a list of challenges that a user needs to clear in order to access protected resources. Commonly used for [Strong Customer Authentication & 2FA](/guides/developer/auth-and-security/sca-and-2fa.md). Learn from our [guide](/guides/developer/auth-and-security/one-time-token) to understand the One Time Token Framework. To ease reading in this document, we will use OTT as an abbreviation for one time token. {% admonition type="info" %} We suggest the following method to check if the OTT is ready to access an SCA protected endpoint: iterate through the `challenges` array and look for any challenge that has `required: true` and `passed: false`. {% /admonition %} {% admonition type="warning" %} The Verify PIN/FaceMap/Device Fingerprint APIs are currently in closed Beta and subject to change. Please speak with your implementation manager if you would like to use these APIs. {% /admonition %} The Challenge Type resource {% #challenge-type .title-3 .m-t-5 %} Enumerated string that indicates what sort of challenge user can do to pass the associated OTT. | Type | Pre-requisite | Trigger | Verify | |------|---------------|---------|--------| | PIN | [Create Pin](/api-reference/user-security/usersecuritypincreate) | - | [Verify Pin](/api-reference/one-time-token/ottpinverify) | | FACE_MAP | [Enrol FaceMap](/api-reference/user-security/usersecurityfacemapenrol) | - | [Verify FaceMap](/api-reference/one-time-token/ottfacemapverify) | | SMS | [Create Phone Number](/api-reference/user-security/usersecurityphonenumbercreate) | [Trigger SMS](/api-reference/one-time-token/ottsmstrigger) | [Verify SMS](/api-reference/one-time-token/ottsmsverify) | | WHATSAPP | [Create Phone Number](/api-reference/user-security/usersecurityphonenumbercreate) | [Trigger WhatsApp](/api-reference/one-time-token/ottwhatsapptrigger) | [Verify WhatsApp](/api-reference/one-time-token/ottwhatsappverify) | | VOICE | [Create Phone Number](/api-reference/user-security/usersecurityphonenumbercreate) | [Trigger Voice](/api-reference/one-time-token/ottvoicetrigger) | [Verify Voice](/api-reference/one-time-token/ottvoiceverify) | | PARTNER_DEVICE_FINGERPRINT | [Create Device Fingerprint](/api-reference/user-security/usersecuritydevicefingerprintcreate) | - | [Verify Device Fingerprint](/api-reference/one-time-token/ottdevicefingerprintverify) | ### Get status of a one time token - [GET /v1/one-time-token/status](https://docs.wise.com/api-reference/one-time-token/ottstatusget.md): Retrieve necessary information to clear a OTT. ### Verify PIN - [POST /v1/one-time-token/pin/verify](https://docs.wise.com/api-reference/one-time-token/ottpinverify.md): {% img src="https://img.shields.io/badge/jose-direct_encryption-blue" /%}{% .d-inline-block %} To clear a PIN challenge listed in a OTT. Notes: 1. User is required to create pin before the verification can be successful. 2. Rate limit may be applied if there are 5 continuous unsuccessful attempts and OTT creation will be blocked for 15 minutes. ### Verify Device Fingerprint - [POST /v1/one-time-token/partner-device-fingerprint/verify](https://docs.wise.com/api-reference/one-time-token/ottdevicefingerprintverify.md): {% img src="https://img.shields.io/badge/jose-direct_encryption-blue" /%}{% .d-inline-block %} To clear a Device Fingerprint challenge listed in an OTT. Notes: 1. User is required to create a device fingerprint before the verification can be successful. 2. Rate limit may be applied if there are 5 continuous unsuccessful attempts and OTT creation will be blocked for 15 minutes. ### Verify FaceMap - [POST /v1/one-time-token/facemap/verify](https://docs.wise.com/api-reference/one-time-token/ottfacemapverify.md): To clear a FACE_MAP challenge listed in a OTT. Notes: 1. User is required to enrol facemap before the verification can be successful. 2. Rate limit may be applied if there are 5 continuous unsuccessful attempts and OTT creation will be blocked for 15 minutes. ### Trigger SMS Challenge - [POST /v1/one-time-token/sms/trigger](https://docs.wise.com/api-reference/one-time-token/ottsmstrigger.md): To trigger a SMS challenge by sending SMS to user verified phone number containing a 6 digit one time password (OTP). This OTP code can be used to clear a SMS challenge by using the Verify SMS endpoint. {% admonition type="warning" %} The Trigger SMS Challenge API is currently in closed Beta and subject to change. Please speak with your implementation manager if you would like to use this API. {% /admonition %} ### Verify SMS Challenge - [POST /v1/one-time-token/sms/verify](https://docs.wise.com/api-reference/one-time-token/ottsmsverify.md): To clear a SMS challenge listed in a OTT. Notes: 1. User is required to have a verified phone number. See create phone number for more information. 2. Trigger SMS Challenge is required to be called first. 3. Since we won't be sending real SMS on sandbox, the OTP Code will always be 111111. {% admonition type="warning" %} The Verify SMS Challenge API is currently in closed Beta and subject to change. Please speak with your implementation manager if you would like to use this API. {% /admonition %} ### Trigger WhatsApp Challenge - [POST /v1/one-time-token/whatsapp/trigger](https://docs.wise.com/api-reference/one-time-token/ottwhatsapptrigger.md): To trigger a WhatsApp challenge by sending WhatsApp message to user verified phone number containing a 6 digit one time password (OTP). This OTP code can be used to clear a WHATSAPP challenge by using the Verify WhatsApp endpoint. {% admonition type="warning" %} The Trigger WhatsApp Challenge API is currently in closed Beta and subject to change. Please speak with your implementation manager if you would like to use this API. {% /admonition %} ### Verify WhatsApp Challenge - [POST /v1/one-time-token/whatsapp/verify](https://docs.wise.com/api-reference/one-time-token/ottwhatsappverify.md): To clear a WHATSAPP challenge listed in a OTT. Notes: 1. User is required to have a verified phone number. See create phone number for more information. 2. Trigger WhatsApp Challenge is required to be called first. 3. Since we won't be sending real WhatsApp message on sandbox, the OTP Code will always be 111111. {% admonition type="warning" %} The Verify WhatsApp Challenge API is currently in closed Beta and subject to change. Please speak with your implementation manager if you would like to use this API. {% /admonition %} ### Trigger Voice Challenge - [POST /v1/one-time-token/voice/trigger](https://docs.wise.com/api-reference/one-time-token/ottvoicetrigger.md): To trigger a Voice challenge by sending voice message to user verified phone number containing a 6 digit one time password (OTP). This OTP code can be used to clear a VOICE challenge by using the Verify Voice endpoint. {% admonition type="warning" %} The Trigger Voice Challenge API is currently in closed Beta and subject to change. Please speak with your implementation manager if you would like to use this API. {% /admonition %} ### Verify Voice Challenge - [POST /v1/one-time-token/voice/verify](https://docs.wise.com/api-reference/one-time-token/ottvoiceverify.md): To clear a VOICE challenge listed in a OTT. Notes: 1. User is required to have a verified phone number. See create phone number for more information. 2. Trigger Voice Challenge is required to be called first. 3. Since we won't be sending real voice message on sandbox, the OTP Code will always be 111111. {% admonition type="warning" %} The Verify Voice Challenge API is currently in closed Beta and subject to change. Please speak with your implementation manager if you would like to use this API. {% /admonition %} ### Get OTT status (v1) (deprecated) - [GET /v1/identity/one-time-token/status](https://docs.wise.com/api-reference/one-time-token/ottstatusgetv1.md): {% admonition type="warning" %} This endpoint is deprecated. Use the new endpoint to get status of a one time token instead. {% /admonition %} Retrieve necessary information to clear a OTT. ## Partner Cases Partner Cases are part of the Partner Support API, allowing partners to open, retrieve and respond to support and operations queries. The endpoints described here allow partners to directly integrate their back end tooling with Wise's, allowing faster responses, better structure to data, and operational efficiencies. {% admonition type="warning" %} The Partner Support APIs are currently in a closed Beta and subject to change. Please speak with your implementation manager if you would like to integrate with these APIs. {% /admonition %} Case Statuses {% #case-statuses .title-3 .m-t-5 %} Partner cases can move through different statuses. | Status | Transitions to | Description | |--------|---------------|-------------| | `CREATING` | OPEN | Cases being created by Wise from a Partner call. Once created, cases move into the open status. | | `OPEN` | PENDING, SOLVED, CLOSED | Cases being actioned by Wise. Partners do not need to action these cases. Note that we may update a case in this status and not change it. | | `PENDING` | OPEN, SOLVED, CLOSED | Cases that require additional information from the partner. You should action these cases by reviewing the newest comment and updating the case. | | `SOLVED` | OPEN, PENDING, CLOSED | Cases that have been solved and scheduled for closure. These can be re-opened by the partner or Wise if needed before closing. | | `CLOSED` | — | Cases that have been solved and closed. Once closed, they cannot be reopened and a new case should be created if needed. | {% img src="/images/diagrams/case-flow.png" /%} ### Create a partner case - [POST /v1/cases](https://docs.wise.com/api-reference/case/casecreate.md): Cases are used to collect or transmit additional information between Partners and Wise. Use this endpoint to create a new case. {% admonition type="warning" %} Please do not include PII in the subject of a case. Any specific details regarding the case that need to be communicated should be included in the description. {% /admonition %} ### Retrieve a partner case by ID - [GET /v1/cases/{caseId}](https://docs.wise.com/api-reference/case/caseget.md): This endpoint returns a partner case based on the specified case ID. ### Retrieve partner case comments - [GET /v1/cases/{caseId}/comments](https://docs.wise.com/api-reference/case/casecommentsget.md): This endpoint returns a comments list object, which is an array of comments that have been associated with the case. Comments are ordered newest to oldest and are not paginated (all comments returned at once). ### Add a partner case comment - [PUT /v1/cases/{caseId}/comments](https://docs.wise.com/api-reference/case/casecommentcreate.md): This endpoint allows for a comment to be placed on a partner case. ## Payin Deposit Detail The payin deposit details API allows you to get the bank details for the account that the customer should send funds to when paying for a Wise transfer via a bank transfer. These details will be provided in the local format for that currency and usually contain bank account information — like IBAN, SWIFT code etc. It also includes the name and address of the receiving bank and the name and address of the Wise entity that owns the bank account, as sometimes these are required to make a payment. ### Retrieve bank transfer deposit details - [GET /v1/profiles/{profileId}/transfers/{transferId}/deposit-details/bank-transfer](https://docs.wise.com/api-reference/payin-deposit-detail/payindepositdetailget.md): Retrieve the bank details for the account that the customer should send funds to when paying for a Wise transfer via a bank transfer. profileId in the request URL refers to the profile that created the transfer. It can be either the personal profile ID, or the business profile ID. The payinBankAccount field allows the bank details to be displayed dynamically in a user interface, by displaying the label and value fields. Currently, this API supports the following currencies: AUD, BGN, BRL, CAD, CHF, CZK, DKK, EUR, GBP, HKD, HRK, HUF, IDR, INR, JPY, MYR, NOK, NZD, PLN, RON, SEK, SGD, TRY, USD. ## Profile A profile represents an identity that can send and receive money through Wise — either a personal profile (an individual) or a business profile (a company). Most API endpoints require a `profileId` parameter, which is the ID of either profile type. ### List profiles for a user account - [GET /v2/profiles](https://docs.wise.com/api-reference/profile/profilelist.md): List of all profiles belonging to user. ### Create a personal profile - [POST /v2/profiles/personal-profile](https://docs.wise.com/api-reference/profile/profilepersonalcreate.md): Create a personal profile for the authenticated user. A personal profile represents an individual and is required before creating transfers or business profiles. {% admonition type="info" %} Use the X-idempotence-uuid header to safely retry requests. If omitted and a profile already exists, the API returns 409 Conflict. You can then retrieve existing profiles via List profiles. {% /admonition %} Field notes {% .title-4 .m-t-3 %} - First and last names are limited to 30 characters each. Truncate if necessary (e.g. when a customer has many middle names). - occupations is required for CA, IN, JP, ID, IL, MX, and within the US for the state NM. - contactDetails are used for mandatory customer notifications and to help identify your customer when contacting Wise support. ### Create a business profile - [POST /v2/profiles/business-profile](https://docs.wise.com/api-reference/profile/profilebusinesscreate.md): It is required that you first create a personal profile with details of the authorized representative of the business. It is currently not possible to create a business profile without first creating a personal profile. {% admonition type="info" %} This request accepts an optional field in the header, X-idempotence-uuid. This should be unique for each Profile you create. In the event that the request fails, you should use the same value again when retrying. If the X-idempotence-uuid header is not provided and a Profile already exists, then you will receive a response with an HTTP status code 409. If this happens, you can retrieve the profiles with the 'List profiles for a user account' API GET /v2/profiles. {% /admonition %} See Business Category for the list of valid firstLevelCategory and secondLevelCategory values. ### Create a business profile (V3, beta) - [POST /v3/profiles/business-profile](https://docs.wise.com/api-reference/profile/profilebusinesscreatev3.md): Create a business profile and its authorized representative in a single request. {% admonition type="warning" %} This endpoint will soon be deprecated, please use the /v2 endpoints instead. {% /admonition %} {% admonition type="info" %} This request accepts an optional field in the header, X-idempotence-uuid. This should be unique for each Profile you create. In the event that the request fails, you should use the same value again when retrying. If the X-idempotence-uuid header is not provided and a Profile already exists, then you will receive a response with an HTTP status code 409. {% /admonition %} See Business Category for the list of valid firstLevelCategory and secondLevelCategory values. ### Retrieve a profile by ID - [GET /v2/profiles/{profileId}](https://docs.wise.com/api-reference/profile/profileget.md): Get profile info by ID. ### Update a personal profile - [PUT /v2/profiles/{profileId}/personal-profile](https://docs.wise.com/api-reference/profile/profilepersonalupdate.md): Update user profile information for a personal profile. {% admonition type="warning" %} If user profile has been verified then there are restrictions on what information is allowed to change. Where permitted, use the update window functionality by opening the update window, submitting the updated information using this endpoint, and finally closing the update window. {% /admonition %} ### Update a business profile - [PUT /v2/profiles/{profileId}/business-profile](https://docs.wise.com/api-reference/profile/profilebusinessupdate.md): Update user profile information for a business profile. {% admonition type="warning" %} If user profile has been verified then there are restrictions on what information is allowed to change. {% /admonition %} Where permitted, use the update window functionality by opening the update window, submitting the updated information using this endpoint, and finally closing the update window. See Business Category for the list of valid firstLevelCategory and secondLevelCategory values. ### Retrieve business representative (beta) - [GET /v3/profiles/{profileId}/business-profile/business-representative](https://docs.wise.com/api-reference/profile/profilebusinessrepresentativeget.md): Get Business Representative info by Business Profile ID. ### Update business representative (beta) - [PUT /v3/profiles/{profileId}/business-profile/business-representative](https://docs.wise.com/api-reference/profile/profilebusinessrepresentativeupdate.md): Update or transfer the Business Representative for the specified Business Profile. {% admonition type="warning" %} This endpoint will soon be deprecated, please use the /v2 endpoints instead. {% /admonition %} Set updateContext to UPDATE_DETAILS to update the existing Business Representative's details, or TRANSFER_OF_AUTHORISATION to transfer authority of the Business Profile to a new Business Representative. {% admonition type="info" %} If the Business Representative has been verified then there are restrictions on what information is allowed to change. {% /admonition %} {% admonition type="info" %} If this Business Representative is shared across multiple Business Profiles, then changes will be reflected for all of the Business Profiles. {% /admonition %} When using TRANSFER_OF_AUTHORISATION, this will overwrite the existing Business Representative. The new Business Representative will need to be verified for KYC purposes. ### Create an identification document - [POST /v1/profiles/{profileId}/verification-documents](https://docs.wise.com/api-reference/profile/profileverificationdocumentcreate.md): Add an identification document to a personal profile. Not applicable to business profiles. For SSN submissions, only type and uniqueIdentifier (9 digits, no letters or symbols) are required. ### Update an identification document - [PUT /v1/profiles/{profileId}/verification-documents](https://docs.wise.com/api-reference/profile/profileverificationdocumentupdate.md): Update an existing identification document on a personal profile. Not applicable to business profiles. This endpoint performs a full replacement of the document details. Any fields not provided in the request body will be set to null on the stored document. Partners must provide all fields they wish to retain. Only partners with a KYC partner onboarding model are permitted to use this endpoint. Non-KYC partners will receive a 400 error. ### Create business directors - [POST /v1/profiles/{profileId}/directors](https://docs.wise.com/api-reference/profile/profiledirectorcreate.md): Adds new directors to the business profile. Returns the list of all directors associated with the business profile. ### List business directors - [GET /v1/profiles/{profileId}/directors](https://docs.wise.com/api-reference/profile/profiledirectorlist.md): Returns the list of director objects associated with the business profile. ### Update business directors - [PUT /v1/profiles/{profileId}/directors](https://docs.wise.com/api-reference/profile/profiledirectorupdate.md): Overrides directors in the business profile. Returns the list of all directors associated with the business profile. ### Create business ultimate owners - [POST /v1/profiles/{profileId}/ubos](https://docs.wise.com/api-reference/profile/profileubocreate.md): Adds new ultimate beneficial owners to the business profile. Returns the list of all ultimate beneficial owners associated with the business profile. All the shareholders that have at least 25% ownership should be submitted via this API. Note that in some cases, we do not require the ownershipPercentage. In these cases, null should be passed as the value. ### List business ultimate owners - [GET /v1/profiles/{profileId}/ubos](https://docs.wise.com/api-reference/profile/profileubolist.md): Returns the list of all ultimate beneficial owners associated with the business profile. ### Update business ultimate owners - [PUT /v1/profiles/{profileId}/ubos](https://docs.wise.com/api-reference/profile/profileuboupdate.md): Overrides ultimate beneficial owners in the business profile. Returns the list of all ultimate beneficial owners associated with the business profile. ### Remove trusted verification - [DELETE /v3/profiles/{profileId}/trusted-verification](https://docs.wise.com/api-reference/profile/profiletrustedverificationremove.md): This endpoint allows partners to remove the verification that was given to the profile through them creating the profile. This does not delete a profile nor archive it, it simply removes the trusted verification from that partner. Note that this uses a client-credentials-token and not a user access_token for authentication. ### Open an update window - [POST /v1/profiles/{profileId}/update-window](https://docs.wise.com/api-reference/profile/profileupdatewindowopen.md): Opens the update window for updating the profile information: details, addresses, directors, owners, others. ### Close an update window - [DELETE /v1/profiles/{profileId}/update-window](https://docs.wise.com/api-reference/profile/profileupdatewindowclose.md): Deletes the update window for updating the profile. ### Check profile verification status - [POST /v3/profiles/{profileId}/verification-status/bank-transfer](https://docs.wise.com/api-reference/profile/profileverificationstatuscheck.md): You can check the verification status of a profile using this API. This is a profile-specific API resource which should be accessed using an access token acquired for the profile. We do not expose any finer details of customer verification. ### Create a profile (V1) (deprecated) - [POST /v1/profiles](https://docs.wise.com/api-reference/profile/profilecreatev1.md): {% admonition type="warning" %} This endpoint is deprecated. Please see the Create Personal Profile and Create Business Profile v2 endpoints. {% /admonition %} Create personal or business user profile. Set type to "personal" or "business". One person cannot have multiple active duplicate user profiles, creating multiple profiles with the same details will fail. When this happens, you should show an error message to the user informing them that they may have an existing Wise account. The customer should then be allowed to link to an existing Wise account. {% admonition type="info" %} For personal profiles, you must submit the profile's address using POST /v1/addresses. Failure to do so will result in an incomplete registration and delayed transactions. {% /admonition %} For business profiles, you must always create a personal profile first. Business profiles cannot be created without a personal profile. See Business Category for the list of valid category and sub-category values for business profiles. ### Update a profile (V1) (deprecated) - [PUT /v1/profiles](https://docs.wise.com/api-reference/profile/profileupdatev1.md): {% admonition type="warning" %} This endpoint is deprecated. Please see the Update Personal Profile and Update Business Profile v2 endpoints. {% /admonition %} Update user profile information. Request and response is same as described in the create profile endpoint, with the addition of the id field. {% admonition type="info" %} If user profile has been verified then there are restrictions on what information is allowed to change, where permitted, use the update window functionality to submit updated data. {% /admonition %} ### Retrieve profile extension requirements (deprecated) - [GET /v1/profiles/{profileId}/extension-requirements](https://docs.wise.com/api-reference/profile/profileextensionrequirementsget.md): {% admonition type="warning" %} This endpoint is deprecated. Please check the Additional Verification endpoints for providing additional verification details for a profile. {% /admonition %} After having a profile created, in some situations we can need more specific information about it. In order to know which fields are required for a given profile, and to send the information over, we expose a few endpoints: - GET /v1/profiles/{profileId}/extension-requirements - POST /v1/profiles/{profileId}/extension-requirements and - POST /v1/profiles/{profileId}/extensions - GET /v1/profiles/{profileId}/extensions The GET and POST profile extension-requirements endpoints help you to figure out which fields are required to create a valid profile for different regions. You can use this data to build a dynamic user interface on top of these endpoints. The POST and GET profile extensions endpoints allow you to send the extra profile information and retrieve it, respectively. This format for dynamic forms is the same as the one used for recipient creation. See Recipient Requirements. Using profile extension requirements {% .title-4 .m-t-3 %} 1. First create a profile. See Create Personal Profile and Create Business Profile. 2. Call GET /v1/profiles/{profileId}/extension-requirements to get the list of fields you need to fill with values in the "details" section for adding information that will make a profile valid. 3. Some fields require multiple levels of fields in the details request. This should be handled by the client based on the refreshRequirementsOnChange field. A top level field can have this field set to true, indicating that there are additional fields required depending on the selected value. To manage this you should create a request with all of the initially requested data and call the POST extension-requirements endpoint. You will be returned a response similar the previously returned data from GET extension-requirements but with additional fields. 4. Once you have built your full profile extension details object you can add it to add information to the profile. Building a user interface {% .title-4 .m-t-3 %} When requesting the form data from the extension-requirements endpoint, the response defines different types of extensions that can be added. Each extension type then has multiple fields describing the form elements required to be shown to collect information from the user. Each field will have a type value, these tell you the field type that your front end needs to render to be able to collect the data. A number of field types are permitted, these are: | type | UI element | |--------|-----------------------------------| | text | A free text box | | select | A selection box/dialog | | radio | A radio button choice between options | | date | A text box with a date picker | Example data is also included in each field which should be shown to the user, along with a regex or min and max length constraints that should be applied as field level validations. You can optionally implement the dynamic validation using the validationAsync field, however these checks will also be done when a completed profile extension is submitted to POST /v1/profiles/{profileId}/extensions. ### Update profile extensions dynamically (deprecated) - [POST /v1/profiles/{profileId}/extension-requirements](https://docs.wise.com/api-reference/profile/profileextensionrequirementspost.md): {% admonition type="warning" %} This endpoint is deprecated. Please check the Additional Verification endpoints for providing additional verification details for a profile. {% /admonition %} Post extension requirements to discover additional required fields based on selected values. See the GET extension-requirements endpoint for full details on how to use these endpoints together. ### Submit profile extensions (deprecated) - [POST /v1/profiles/{profileId}/extensions](https://docs.wise.com/api-reference/profile/profileextensionscreate.md): {% admonition type="warning" %} This endpoint is deprecated. Please check the Additional Verification endpoints for providing additional verification details for a profile. {% /admonition %} Submit the extra profile information gathered from the extension requirements. See the GET extension-requirements endpoint for full details on how to use these endpoints together. ### Retrieve profile extensions (deprecated) - [GET /v1/profiles/{profileId}/extensions](https://docs.wise.com/api-reference/profile/profileextensionsget.md): {% admonition type="warning" %} This endpoint is deprecated. Please check the Additional Verification endpoints for providing additional verification details for a profile. {% /admonition %} Retrieve the extra profile information previously submitted via extensions. See the GET extension-requirements endpoint for full details on how to use these endpoints together. ## Quote The quote resource defines the basic information required for a Wise transfer - the currencies to send between, the amount to send and the profile who is sending the money. The profile _must_ be included when creating a quote. Quote is one of the required resources to create a transfer, along with the recipient who is to receive the funds. The quote response contains other information such as the exchange rate, the estimated delivery time and the methods the user can pay for the transfer. Not all of this information may apply to your use case. Upon creating a quote the current mid-market exchange rate is locked and will be used for the transfer that is created from the quote. The rate will be locked for 30 minutes to give a user time to complete the transfer creation flow. ### Create a quote (unauthenticated) - [POST /v3/quotes](https://docs.wise.com/api-reference/quote/quotecreateunauthenticated.md): Use this endpoint to get example quotes for people to see the exchange rate and fees Wise offers before a user has created or linked an account. This can drive a version of the quote screen that shows the user what Wise offers before they sign up. Note that this endpoint does not require a token to create the resource, however, since it is just an example, the returned quote has no ID so can't be used later to create a transfer. In order to get an accurate partner fee, we require a client credentials token to be provided. If you are a partner and would like your fee to be included in the quote returned, you must provide your auth token. If not, you do not require the Authorization header. {% admonition type="info" %} Unauthenticated quotes cannot be used to create transfers, they are meant for illustration purposes in partner interfaces only. Make sure to create an authenticated quote during the transfer creation flow. {% /admonition %} ### Create a quote (authenticated) - [POST /v3/profiles/{profileId}/quotes](https://docs.wise.com/api-reference/quote/quotecreate.md): {% admonition type="info" %} You must use a user access token to authenticate this call and supply the profile with which the quote should be associated. This ensures that quote can be used to create a transfer. {% /admonition %} If you are funding the transfer from a Multi Currency Balance, you must set the payIn as BALANCE to get the correct pricing in the quote. Not doing so will default to BANK_TRANSFER and the fees will be inconsistent between quote and transfer. {% admonition type="info" %} When SWIFT_OUR is set as payOut value, it enables payment protection for swift recipients for global currency transfers. By using this payOut method, you can guarantee your customers that the fee will be charged to the sender and can ensure that the recipient gets the complete target amount. {% /admonition %} #### Response The following describes the fields of the quote response that may be useful when building your integration. The payOut field is used to select the correct entry in the paymentOptions array in order to know which fees to display to your customer. Find the paymentOption that matches the payOut field shown at the top level of the quote resource and payIn based on the settlement model the bank is using. By default, this is BANK_TRANSFER, unless you are using a prefunded or bulk settlement model. The payOut field will change based on the type of recipient you add to the quote in the PATCH /quote call, for example to-USD swift_code or to-CAD interac have different fees. For example sending USD to a country other than the United States is supported but with different fees to domestic USD transfers. Please see the later section on Global Currencies to learn more about how to offer this useful feature. For each paymentOption there is a price field. It gives a full breakdown of all the taxes, fees and discounts. It is preferable to refer to this structure to show breakdowns and totals, rather than the fee structure, found as well in each paymentOption element, that only gives a summary and is not able to surface important specifics such as taxes. When showing the price of a transfer always show the 'price.total.value.amount' of a payment option. #### Disabled Payment Options Each payment option is either enabled or disabled based on the disabled value. Disabled payment options should be shown to the user in a disabled state in most cases. This ensures users are given the options that they are familiar with regardless of their availability, as well as with options that can be beneficial to their accounts. The option.disabledReason contains both the code and message, with the message being the user-friendly text to surface to the user if necessary. #### Transfer Nature for BRL When creating or updating a quote, the transfer nature can be set. This is a requirement for transfers to or from BRL and impacts the fees we charge on the quote, specifically the IOF. Note that IOF is determined based on the transfer nature, sender information, and recipient information. The default IOF will be included in a quote until all relevant information has been included. {% admonition type="info" %} Omitting transfer nature will not prevent the transfer from being created or even funded. However, when attempting to process the transfer, it will be blocked and the money will be refunded to the sender. {% /admonition %} #### Pricing Configuration When creating or updating a quote, partners that have flexible partner pricing enabled are able to override the pricing configuration dynamically. To learn more on how to use this feature, please see the Flexible Partner Pricing Guide ### Retrieve a quote by ID - [GET /v3/profiles/{profileId}/quotes/{quoteId}](https://docs.wise.com/api-reference/quote/quoteget.md): Get quote info by ID. If the quote has expired (not used to create a transfer within 30 minutes of quote creation), it will only be accessible for approximately 48 hours via this endpoint. ### Update a quote - [PATCH /v3/profiles/{profileId}/quotes/{quoteId}](https://docs.wise.com/api-reference/quote/quoteupdate.md): You should update a quote using a PATCH call to add a recipient. This will update the saved quote's data based on who and where the money will be sent to. Updating the quote with a recipient may cause the available payment options, prices and estimated delivery times to change from the original quoted amounts. This is due to the fact that sending some currencies to some destinations costs a different amount based on the payment networks we use, for example sending USD to a country outside the USA uses international rather than domestic payment networks and as such costs more, or sending CAD over the Interac network is a more expensive operation. When updating a quote the payOut field may change to denote the payment option you should select when sending to this recipient. For example sending USD to a swift_code recipient or CAD to an interac recipient will change payOut to SWIFT or INTERAC respectively. This field defaults to BANK_TRANSFER so it can be used in all cases to help select the correct paymentOption and hence show the correct pricing to users. If you want to provide more transparency in terms of fees charged when your customers create quote with swift recipient for global currencies, you might consider to set payOut field with SWIFT_OUR value. This will ensure that the recipient receives complete target amount. In this case, where pricing changes after a user selects recipient, you should show a message to your customer before confirming the transfer. Please see the section on Global Currencies to learn more how and why this works and the messaging you need to display. #### Transfer Nature for BRL When creating or updating a quote, the transfer nature can be set. This is a requirement for transfers to or from BRL and impacts the fees we charge on the quote, specifically the IOF. Note that IOF is determined based on the transfer nature, sender information, and recipient information. The default IOF will be included in a quote until all relevant information has been included. {% admonition type="info" %} Omitting transfer nature will not prevent the transfer from being created or even funded. However, when attempting to process the transfer, it will be blocked and the money will be refunded to the sender. {% /admonition %} ## Rate Current and historical exchange rates by currency routes. ### Retrieve current rates - [GET /v1/rates](https://docs.wise.com/api-reference/rate/rateget.md): {% admonition type="warning" %} The from, to, and group parameters are not testable in our Sandbox environment at this time. {% /admonition %} GET /v1/rates Fetch latest exchange rates of all currencies. GET /v1/rates?source=EUR&target=USD Fetch latest exchange rate of one currency pair. GET /v1/rates?source=EUR&target=USD&time=2019-02-13T14:53:01 Fetch exchange rate of specific historical timestamp. GET /v1/rates?source=EUR&target=USD&from=2019-02-13T14:53:01&to=2019-03-13T14:53:01&group=day Fetch exchange rate history over period of time with daily interval. GET /v1/rates?source=EUR&target=USD&from=2019-02-13T14:53:01&to=2019-03-13T14:53:01&group=hour Fetch exchange rate history over period of time with hourly interval. GET /v1/rates?source=EUR&target=USD&from=2019-02-13T14:53:01&to=2019-03-13T14:53:01&group=minute Fetch exchange rate history over period of time with 1 minute interval. {% admonition type="warning" %} This endpoint only supports Bearer authentication for non-Affiliate partners. {% /admonition %} ## Recipient Account Recipient or beneficiary is the one who will receive the funds. Recipient account endpoints use a mixture of our v1 and v2 APIs. Please ensure you address the right version to get the expected results. {% admonition type="info" %} All recipient IDs are cross compatible with v1 and v2. {% /admonition %} ### Create a recipient account - [POST /v1/accounts](https://docs.wise.com/api-reference/recipient/recipientcreate.md): Creates a recipient account. A recipient is a person or institution who is the ultimate beneficiary of your payment. Recipient data includes three data blocks: - General data - the personal details of an individual and basic information about a business. - Bank details - account numbers, routing numbers, and other region-specific bank details. - Address details - country and street address of an individual or business. Notes: - Date of Birth is optional; consult the account-requirements APIs to confirm if it is needed or contact Wise Support. - ownedByCustomer is optional but strongly recommended for self-transfers. - Email recipients: testing transfers to email recipients in sandbox is not currently possible. Refund recipients: - Use refund=true query parameter. #### Bank account data There are many different variations of bank account details needed depending on recipient target currency. For example: - GBP — sort code and account number - BGN, CHF, DKK, EUR, GEL, GBP, NOK, PKR, PLN, RON, SEK — IBAN - USD — routing number, account number, account type - INR — IFSC code, account number - etc. #### Address data Recipient address data is required only if target currency is USD, PHP, THB or TRY, or if the source currency is USD or AUD. Address fields can include: - Country - State (US, Canada, Brazil) - City - Address line - Zip code #### accountHolderName rules - Personal recipients: Full names must include more than one name, and both first and last name must have more than one character. Numbers are not allowed. - Business recipients: Business names must be in full and can be a single name. The full name cannot be just a single character, but can be made up of a set of single characters (e.g. "A" is not permitted but "A 1" or "A1" is permitted). - Special characters _()'*,. are allowed for personal and business names. - In general the following regex describes permitted characters: [0-9A-Za-zÀ-ÖØ-öø-ÿ-_()'*,.\s]. Recipient requirements vary depending on recipient type/currency route. A GBP example is provided here. Many fields may be null in examples. To determine which fields are required for which currency, use the Recipient Requirements endpoint. #### Create a refund recipient account POST /v1/accounts?refund=true Sometimes we may need to refund the transfer back to the sender - see the transfer status here for cases when this may happen. A refund recipient is a person or institution where we will refund transfer the money back to if necessary. This is not always a mandatory resource to create. If the funds are sent over a fast local payment network we can usually infer the refund recipient from the bank transaction that funded the transfer. Please discuss this with your Wise implementation team if you are unsure if the refund recipient is needed. If funds are sent using a slow domestic payment network, or you are using a bulk settlement model, we may require you to share the bank details of the source bank account. The format of the request payload for refund recipient creation will be different depending on the currency you will send transfers from. You may use the account requirements endpoint to understand the payload requirements when creating the refund recipient for a specific currency. The refund recipient account ID returned in the response is used as sourceAccount when creating transfers. #### Create an email recipient account POST /v1/accounts {% admonition type="warning" %} Please contact us before attempting to use email recipients. We do not recommend using this feature except for certain use cases. {% /admonition %} If you don't know recipient bank account details you can set up an email recipient; Wise will collect bank details directly from the recipient. Wise will email your recipient with a link to collect their bank account details securely. After the bank account details have been provided Wise will complete your transfer. It's best to confirm that this recipient type is available to your transaction by checking if the "type": "email" class is present in the response from GET /v1/quotes/{quoteId}/account-requirements — see account requirements for more information on how to use this endpoint. If planning to send multiple currencies to a single recipient, you will need to create a separate email recipient resource for this beneficiary, for every currency you intend to send to them. We highly encourage you to provide the {profileId} if your recipient is receiving a payment from your Business account, especially if you have multiple businesses, or have multiple users administrating your business account. Please be aware of the following caveats: - Testing of transfers to email recipients in sandbox is not currently possible. - Recipients will be required to enter bank details every time a payment is made. - We highly encourage you to provide the profileId if your recipient is receiving a payment from your Business account, especially if you have multiple businesses, or have multiple users administrating your business account. - Please refer to our help page on how this works and any additional constraints not mentioned in this section. ### List recipient accounts - [GET /v2/accounts](https://docs.wise.com/api-reference/recipient/recipientlist.md): Fetch a list of the user's recipient accounts. Use the profileId parameter to filter by the profile who created the accounts, you should do this based on the personal or business profile ID you have linked to, based on your use case. Other filters are listed below for your convenience, for example currency is a useful filter to use when presenting the user a list of recipients to choose from in the case they have already submitted the target currency in your flow. #### Pagination Pagination is supported for this endpoint. The response includes the seekPositionForNext and size parameters to manage this. It works by setting size and seekPosition parameters in the call. Set the value in the seekPositionForNext of the previous response into the seekPosition parameter of your subsequent call in order to get the next page. To get the current page again, use the seekPositionForCurrent value. #### Sorting You can also set the sort parameter to control the sorting of the response, for example: ?sort=id,asc sort by id ascending. ?sort=id,desc sort by id descending. ?sort=currency,asc sort by currency ascending. All query parameters are optional. ### Get account by ID - [GET /v2/accounts/{accountId}](https://docs.wise.com/api-reference/recipient/recipientget.md): Get recipient account info by ID. {% admonition type="info" %} V1 and v2 versions are cross compatible, but the v2 endpoint provides additional features. {% /admonition %} ### Deactivate a recipient account - [DELETE /v2/accounts/{accountId}](https://docs.wise.com/api-reference/recipient/recipientdeactivate.md): Deletes a recipient by changing its status to inactive ("active": false). Requesting to delete a recipient that is already inactive returns HTTP 403 (Forbidden). {% admonition type="info" %} Only active recipients can be deleted and a recipient cannot be reactivated, however you can create a new recipient with the same details instead if necessary. {% /admonition %} ### Retrieve recipient account requirements dynamically - [GET /v1/quotes/{quoteId}/account-requirements](https://docs.wise.com/api-reference/recipient/recipientaccountrequirementsget.md): {% admonition type="info" %} Please note that to use v1.1 Accept-Minor-Version: 1 request header must be set. {% /admonition %} GET /v1/quotes/{quoteId}/account-requirements POST /v1/quotes/{quoteId}/account-requirements GET /v1/account-requirements?source=EUR&target=USD&sourceAmount=1000 You can use the data returned by this API to build a dynamic user interface for recipient creation. The GET and POST account-requirements endpoints help you to figure out which fields are required to create a valid recipient for different currencies. This is a step-by-step guide on how these endpoints work. Use the GET endpoint to learn what datapoints are required to send a payment to your beneficiary. As you build that form, use the POST endpoint to learn if any additional datapoints are required as a result of passing a field that has "refreshRequirementsOnChange": true in the GET response. You should be posting the same recipient account payload that will be posted to /v1/accounts. An example of this would be address.country. Some countries, like the United States, have a lower level organization, "state" or "territory". After POSTing the recipient payload with address.country = "US", the list of possible states will appear in the response. The third endpoint above is used to get account requirements for a specific currency route and amount without referring to a quote but with the amount, source and target currencies passed as URL parameters. Generally this approach is not recommended, you should have your user create a quote resource first and use this to generate the recipient account requirements. This is because some payout methods will only surface when the profile-context is known, for example (at the time of this writing), Business Payments to Chinese Yuan use a different payout method than what is revealed by GET /v1/account-requirements?source=USD&target=CNY&sourceAmount=1000. All new integrations should use the v1.1 of GET and POST account requirements, enabled using the Accept-Minor-Version header. It enables you to fetch the requirements including both the recipient name and email fields in the dynamic form, simplifying implementation of the form. Name and email address dynamic fields are required to support currencies such as KRW, JPY and RUB, and also remove the need for manual name validation. These endpoints allow use of both v1 and v2 quotes using long or UUID based IDs, supporting legacy implementations using v1 quotes. These endpoints accept an optional query parameter originatorLegalEntityType. When the transfer is initiated by a Third Party Partner we are not aware whether the actual sender is a business or person. In such cases, this parameter should be passed to receive correct requirements. The legal entity type should be one of the following values: BUSINESS, PRIVATE. This parameter is optional and the default value is the type of the partner profile. #### Collecting Recipient Address Normally our account requirements will instruct when a recipient address is required. However, in some situations it's desirable to force the requirement so that an address can be provided to Wise. To do this, add the query parameter ?addressRequired=true to your request and address will always be returned as a required field. {% admonition type="warning" %} Address requirement fields are subject to change. Your integration should be built in a way to handle unrecognized or changed fields. {% /admonition %} ### Retrieve recipient account requirements dynamically (step-by-step) - [POST /v1/quotes/{quoteId}/account-requirements](https://docs.wise.com/api-reference/recipient/recipientaccountrequirementspost.md): POST the same recipient account payload that you will POST to /v1/accounts. Use this endpoint after setting any field that has refreshRequirementsOnChange=true in the GET response, to discover any additional required fields. See the GET endpoint for a full overview of how the account requirements flow works. ### Check account and quote compatibility - [POST /v2/accounts/{accountId}/quotes/{quoteId}/compatibility](https://docs.wise.com/api-reference/recipient/recipientcompatibilitycheck.md): Use this endpoint to check the compatibility of a recipient account with a quote before creating a transfer. This validation includes: - Re-validating the recipient account details - Checking all required fields are present (e.g., recipient address for USD transfers) - Verifying account details with the recipient's bank (for supported currencies) This endpoint is optional but useful to identify potential issues before transfer creation. {% admonition type="info" %} The confirmations field is only populated for currencies with recipient verification enabled. If absent, only standard validations apply. {% /admonition %} ### Accept confirmation outcomes - [PATCH /v2/accounts/{accountId}/confirmations](https://docs.wise.com/api-reference/recipient/recipientconfirmationsaccept.md): When requiresCustomerAcceptance is true in the confirmation outcomes, the recipient cannot be used for a transfer until the customer explicitly confirms the details. You must present the mismatch to the customer and get their approval. {% admonition type="warning" %} If the confirmation result contained a quoteId then the acceptance request must also specify that as part of the query parameters, otherwise the request will be rejected. {% /admonition %} ### List recipient accounts (v1) (deprecated) - [GET /v1/accounts](https://docs.wise.com/api-reference/recipient/recipientlistv1.md): {% admonition type="warning" %} This is a deprecated v1 endpoint. For new integrations please use the v2 list endpoint. {% /admonition %} Fetch a list of the user's recipient accounts. Use the currency and profile parameters to filter by currency and/or the owning user profile ID. This endpoint does not support pagination, so please filter by currency to ensure a reasonable response time. Both query parameters are optional. ### Get account by ID (v1) (deprecated) - [GET /v1/accounts/{accountId}](https://docs.wise.com/api-reference/recipient/recipientgetv1.md): {% admonition type="warning" %} This is a deprecated v1 endpoint. For new integrations please use the v2 get endpoint. {% /admonition %} Get recipient account info by ID. ### Check account and quote compatibility (v1) (deprecated) - [POST /v1/accounts/{accountId}/quotes/{quoteId}/compatibility](https://docs.wise.com/api-reference/recipient/recipientcompatibilitycheckv1.md): {% admonition type="warning" %} This is a deprecated v1 endpoint. For new integrations please use the v2 compatibility endpoint. {% /admonition %} {% admonition type="info" %} Use this version if you are fetching recipients through the v1 API. There are no functional differences between v1 and v2, but the field paths referenced in the response differ between the v1 and v2 recipient resources. {% /admonition %} Use this endpoint to check the compatibility of a recipient account with a quote before creating a transfer. This validation includes: - Re-validating the recipient account details - Checking all required fields are present (e.g., recipient address for USD transfers) - Verifying account details with the recipient's bank (for supported currencies) This endpoint is optional but recommended to identify potential issues before transfer creation. {% admonition type="info" %} The confirmations field is only populated for currencies with recipient verification enabled. If absent, only standard validations apply. {% /admonition %} ## Simulation Use these endpoints to simulate key actions in the sandbox environment, including transfer state changes, balance top-ups, card transactions, KYC reviews, and incoming payments. {% admonition type="info" %} These features are limited to sandbox only. {% /admonition %} ### Simulate transfer state change - [GET /v1/simulation/transfers/{transferId}/{status}](https://docs.wise.com/api-reference/simulation/simulationtransferstatechange.md): Changes the transfer status to the specified state. The available state transitions are: - processing — from incoming_payment_waiting - funds_converted — from processing. Refer to regional guides for special regional requirements. - outgoing_payment_sent — from funds_converted - bounced_back — from outgoing_payment_sent - funds_refunded — from bounced_back. Will not trigger a refund webhook. {% admonition type="warning" %} Simulation does not work with email transfers. {% /admonition %} {% admonition type="warning" %} You need to fund the transfer before calling simulation endpoints. Calling the processing endpoint is required even after the funding call has changed the transfer state to processing automatically. {% /admonition %} {% admonition type="info" %} While transfer state simulation calls will respond with 200 in real time, the process internally is asynchronous. Please ensure you give at least 5 seconds in between simulation calls. {% /admonition %} ### Simulate verification for a profile - [POST /v1/simulation/profiles/{profileId}/verifications](https://docs.wise.com/api-reference/simulation/simulationverification.md): Changes a specific profile's verification state to PASSED. This is useful for testing the profiles#verification-state-change webhook and is a prerequisite for setting up a Multi-Currency Account (MCA). Accepts both user and application API tokens. ### Simulate verification for all profiles - [POST /v1/simulation/verify-profile](https://docs.wise.com/api-reference/simulation/simulationverifyprofile.md): Verifies all profiles associated with the authenticated user, changing their verification state to PASSED. This is useful for testing the profiles#verification-state-change webhook and is a prerequisite for setting up a Multi-Currency Account (MCA). Accepts user API tokens only. The profiles are identified via the token. ### Simulate a balance top-up - [POST /v1/simulation/balance/topup](https://docs.wise.com/api-reference/simulation/simulationbalancetopup.md): Simulates a top-up so that a balance can be used to fund transfers and/or card spend. ### Simulate a card transaction authorisation - [POST /v2/simulation/spend/profiles/{profileId}/cards/{cardToken}/transactions/authorisation](https://docs.wise.com/api-reference/simulation/simulationcardtransactionauthorisation.md): Simulates a card transaction authorisation request in the sandbox environment. It can simulate ATM withdrawals, POS purchases, e-commerce transactions, and refunds. This is an authorisation hold, where funds are held, but not yet captured by the acquirer. The cardNumber represents the 16-digit Primary Account Number (PAN) of the card, and must be a valid PAN retrieved from sensitive card details. Please follow the detailed guide on retrieving sensitive card details. #### Refund A refund is a 2-step process: first authorise with transactionType set to REFUND, then clear using the clearing endpoint with the same transaction type. {% admonition type="warning" %} Refund simulation doesn't work with Mastercard. {% /admonition %} ### Simulate a card transaction clearing - [POST /v1/simulation/spend/profiles/{profileId}/cards/{cardToken}/transactions/clearing](https://docs.wise.com/api-reference/simulation/simulationcardtransactionclearing.md): Simulates a transaction clearing request in the sandbox environment. This is done after the authorisation. The ref field can be copied from the reference object in the authorisation response. To clear a previous authorisation, the ref details must match the previous authorisation request. The amount does not have to match the previous authorisation request, it can be more or less than the authorisation request amount. {% admonition type="warning" %} Clearing simulation doesn't work with Mastercard. {% /admonition %} #### Refund A refund is a 2-step process: first authorise with transactionType set to REFUND, then clear using this endpoint with the same transaction type. ### Simulate a card transaction reversal - [POST /v1/simulation/spend/profiles/{profileId}/cards/{cardToken}/transactions/reversal](https://docs.wise.com/api-reference/simulation/simulationcardtransactionreversal.md): Simulates a transaction reversal request in the sandbox environment. The amount.value field can be set to 0 for a full reversal, or a positive value that represents the intended final value of the transaction after a partial reversal. For example, if a transaction value was originally 10 SGD, and the intended final value is 3 SGD, amount.value should be set to 3. This means there is a partial refund of 7 SGD. ### List simulated card transactions - [GET /v2/simulation/spend/profiles/{profileId}/cards/{cardToken}/transactions](https://docs.wise.com/api-reference/simulation/simulationcardtransactions.md): Returns a list of simulated card transactions, in descending order of creation time. To retrieve more details of a transaction, use the get card transaction by ID endpoint. ### Simulate card production state change - [POST /v1/simulation/spend/profiles/{profileId}/cards/{cardToken}/production](https://docs.wise.com/api-reference/simulation/simulationcardproduction.md): Simulates a card production status change in the sandbox environment. {% admonition type="warning" %} Please ensure that you have created a physical card order with KIOSK_COLLECTION delivery method and that you produce the card before calling this endpoint to simulate various card production statuses. {% /admonition %} ### List KYC review requirements - [GET /v2/simulation/profiles/{profileId}/kyc-reviews/{kycReviewId}/requirements](https://docs.wise.com/api-reference/simulation/simulationkycreviewrequirementslist.md): Lists all blocking requirements for a KYC (Know Your Customer) review. These outstanding KYC requirements typically act as "blocking requirements", preventing actions like creating transfers. ### Simulate adding new requirement - [POST /v2/simulation/profiles/{profileId}/kyc-reviews/{kycReviewId}/requirements/add](https://docs.wise.com/api-reference/simulation/simulationkycreviewrequirementsadd.md): Creates a new requirement for a KYC (Know Your Customer) review for a business profile. {% admonition type="warning" %} This can only be used for business profiles. It creates a static BUSINESS_USE_CASE requirement only. {% /admonition %} ### Simulate requirement submission - [POST /v2/simulation/profiles/{profileId}/kyc-reviews/{kycReviewId}/requirements/submit](https://docs.wise.com/api-reference/simulation/simulationkycreviewrequirementssubmit.md): Simulates providing everything needed for a particular KYC requirement. This can be used in place of going through a hosted journey on the browser. {% admonition type="info" %} This functionality only works for the following requirements: TRANSFER_PURPOSE, ID_DOCUMENT_WITH_LIVENESS, SOURCE_OF_FUNDS, and any other that has the ___ delimiter in them. {% /admonition %} ### Simulate verifying a KYC review - [POST /v2/simulation/profiles/{profileId}/kyc-reviews/{kycReviewId}/verify](https://docs.wise.com/api-reference/simulation/simulationkycreviewverify.md): Verifies requirement(s) on an existing KYC (Know Your Customer) review. Can be used after a user has provided input for a requirement through the hosted journey or simulated the requirement submission. ### Simulate incoming bank transfer - [POST /v1/simulation/profiles/{profileId}/bank-transactions/import](https://docs.wise.com/api-reference/simulation/simulationbanktransactionimport.md): Simulates a bank transfer into a profile's account details. This will create a payment into the user's account details and balance for the specified amount and currency. Please refer to the Bank Account Details API reference for more information on setting up bank details to receive money. {% admonition type="info" %} This functionality only works for the following currencies: USD, EUR, GBP. Returns a 400 error when account details for the specified currency do not exist. {% /admonition %} ### Simulate incoming Swift payment - [POST /v1/simulation/profiles/{profileId}/swift-in](https://docs.wise.com/api-reference/simulation/simulationswiftin.md): Simulates an incoming Swift transfer into a profile's account details. This will create a payment into the user's account details and balance for the specified amount and currency. Using sandbox, you can test the initial tech build for webhook subscriptions, balance statements, and sweeping funds. If the request is successful the transfer is logged in our back office, which triggers a swift-in#credit event and results in a balance update. {% admonition type="info" %} While most fields are optional, default values will be provided as needed. {% /admonition %} ## Spend Controls Control which card transactions are permitted by creating rules based on merchant category code (MCC) or transaction currency. An authorisation rule dictates whether transactions should be declined or approved based on a pre-determined set of rules. A transaction can only pass if it satisfies all the applied rules. Creating a rule has no practical implication until it is [applied](/api-reference/spend-controls/spendcontrolsruleapply). Applying a rule results in the authorisation rule being evaluated against every incoming card authorisation request. Rules are scoped at the application level. Use a [client credentials token](/api-reference/oauth-token/oauthtokencreate) to call these endpoints. ### Add a new authorisation rule - [POST /v3/spend/applications/{clientId}/spend-controls/rules](https://docs.wise.com/api-reference/spend-controls/spendcontrolsrulecreate.md): Creates an authorisation rule. It won't be enabled unless it is applied. {% admonition type="warning" %} An ALLOW rule permits only the transactions that match the specified criteria and blocks all others. For instance, a rule allowing SGD transactions will block all transactions that are not in SGD. {% /admonition %} ### List all authorisation rules - [GET /v3/spend/applications/{clientId}/spend-controls/rules](https://docs.wise.com/api-reference/spend-controls/spendcontrolsruleslist.md): Retrieves all the existing authorisation rules, regardless of whether or not they are applied. ### Apply an authorisation rule - [POST /v3/spend/applications/{clientId}/spend-controls/rules/apply](https://docs.wise.com/api-reference/spend-controls/spendcontrolsruleapply.md): Apply an authorisation rule. This will result in the rule being evaluated against every incoming card authorisation request. ### Unapply an authorisation rule - [POST /v3/spend/applications/{clientId}/spend-controls/rules/unapply](https://docs.wise.com/api-reference/spend-controls/spendcontrolsruleunapply.md): Deactivates an authorisation rule. This will result in all card transactions not being evaluated against this rule. The rule still exists and can be applied again. ### List applied authorisation rules - [GET /v3/spend/applications/{clientId}/spend-controls/rules/applied](https://docs.wise.com/api-reference/spend-controls/spendcontrolsappliedruleslist.md): Returns the list of all the active authorisation rules that have been applied. ### Delete an authorisation rule - [DELETE /v3/spend/applications/{clientId}/spend-controls/rules/{ruleId}](https://docs.wise.com/api-reference/spend-controls/spendcontrolsruledelete.md): Deletes an authorisation rule that is currently not applied. If a rule is applied, you should unapply the rule before deleting it. ## Spend Limits Manage spending limits applied to profiles and cards. Profile limits are shared across all cards under the same profile, while card limits apply to individual cards. For more details on how profile and card limits interact, see the [card management guide](/guides/product/issue-cards/card-management#spend-limits). ### Retrieve profile limits - [GET /v4/spend/profiles/{profileId}/spend-limits](https://docs.wise.com/api-reference/spend-limits/spendlimitsprofileget.md): Retrieves the spend limits that are configured for a profile. ### Update profile limits - [PATCH /v4/spend/profiles/{profileId}/spend-limits](https://docs.wise.com/api-reference/spend-limits/spendlimitsprofileupdate.md): Update profile daily and monthly spend limits for PURCHASE or ATM_WITHDRAWAL. Both daily and monthly must be set. ### Retrieve card limits - [GET /v4/spend/profiles/{profileId}/cards/{cardToken}/spend-limits](https://docs.wise.com/api-reference/spend-limits/spendlimitscardget.md): Retrieves the spend limits that are configured for a card. ### Create or update card limits - [PATCH /v4/spend/profiles/{profileId}/cards/{cardToken}/spend-limits](https://docs.wise.com/api-reference/spend-limits/spendlimitscardupdate.md): Create or update card transaction, daily, monthly or lifetime spend limits. ### Delete card limits - [DELETE /v4/spend/profiles/{profileId}/cards/{cardToken}/spend-limits/{granularity}](https://docs.wise.com/api-reference/spend-limits/spendlimitscarddelete.md): Delete card spend limits for a specific granularity. ### Retrieve profile spend limits (deprecated) - [GET /v3/spend/profiles/{profileId}/spending-limits](https://docs.wise.com/api-reference/spend-limits/spendcontrolsprofilelimitsget.md): Retrieves the spending limits that are configured for a profile. {% admonition type="warning" %} This endpoint has been deprecated. Use Retrieve profile limits instead. {% /admonition %} ## Strong Customer Authentication Strong Customer Authentication (SCA) is a regulatory requirement introduced under the Second Payment Services Directive (PSD2) in the European Economic Area (EEA). It aims to enhance security and reduce fraud risks. These endpoints allow your customers to comply with SCA, ensuring seamless integration over API while meeting security requirements. Please read the [SCA over API guide](/guides/developer/auth-and-security/sca-over-api) to understand how SCA integration works. SCA is required for high-risk and low-risk operations. On low-risk operations, clearing SCA once allows a 5-minute window where SCA won't be requested again. {% admonition type="info" %} Please reach out to your Implementation Manager to determine which challenges can be enabled. {% /admonition %} ### Create a PIN - [POST /v2/profiles/{profileId}/pin](https://docs.wise.com/api-reference/strong-customer-authentication/scapincreate.md): Creates a new PIN factor used to resolve a SCA knowledge challenge type. The request and response are encrypted using the JOSE framework. Please refer to the SCA over API guide to understand how encryption and decryption work. ### Delete a PIN - [DELETE /v2/profiles/{profileId}/pin](https://docs.wise.com/api-reference/strong-customer-authentication/scapindelete.md): Deletes a PIN associated to a profile. To update a PIN for a profile, use this endpoint followed by Create a PIN. {% admonition type="warning" %} This operation is irreversible. {% /admonition %} ### Verify a PIN - [POST /v2/profiles/{profileId}/pin/verify](https://docs.wise.com/api-reference/strong-customer-authentication/scapinverify.md): Verifies a PIN challenge when calling a SCA-secured endpoint. Make sure to create a PIN before using this endpoint. The request and response are encrypted using the JOSE framework. Please refer to the SCA over API guide to understand how encryption and decryption work. ### Create a device fingerprint - [POST /v2/profiles/{profileId}/device-fingerprints](https://docs.wise.com/api-reference/strong-customer-authentication/scadevicefingerprintcreate.md): Creates a new device fingerprint factor used to resolve a SCA possession challenge type. The request and response are encrypted using the JOSE framework. Please refer to the SCA over API guide to understand how encryption and decryption work. ### Verify a device fingerprint - [POST /v2/profiles/{profileId}/device-fingerprints/verify](https://docs.wise.com/api-reference/strong-customer-authentication/scadevicefingerprintverify.md): Verifies a device fingerprint challenge when calling a SCA-secured endpoint. Make sure to create a device fingerprint before using this endpoint. The request and response are encrypted using the JOSE framework. Please refer to the SCA over API guide to understand how encryption and decryption work. ### Delete a device fingerprint - [DELETE /v2/profiles/{profileId}/device-fingerprints/{deviceFingerprintId}](https://docs.wise.com/api-reference/strong-customer-authentication/scadevicefingerprintdelete.md): Deletes a device fingerprint associated to a profile. Include the deviceFingerprintId in the URL to delete a device fingerprint. This ID is provided in the response when the device fingerprint is created. {% admonition type="warning" %} This operation is irreversible. {% /admonition %} ### Create a facemap - [POST /v2/profiles/{profileId}/facemaps](https://docs.wise.com/api-reference/strong-customer-authentication/scafacemapcreate.md): Creates a new facemap factor used to resolve a SCA inherence challenge type. A facemap should be exported from your FaceTec server using the SDK's export API. Please use Wise's FaceTec public key to encrypt the facemap during the export process. ### Delete a facemap - [DELETE /v2/profiles/{profileId}/facemaps](https://docs.wise.com/api-reference/strong-customer-authentication/scafacemapdelete.md): Deletes a facemap associated to a profile. To update a facemap for a profile, use this endpoint followed by Create a facemap. {% admonition type="warning" %} This operation is irreversible. {% /admonition %} ### Verify a facemap - [POST /v2/profiles/{profileId}/facemaps/verify](https://docs.wise.com/api-reference/strong-customer-authentication/scafacemapverify.md): Verifies a facemap challenge when calling a SCA-secured endpoint. Make sure to create a facemap before using this endpoint. A facemap should be exported from your FaceTec server using the SDK's export API. Please use Wise's FaceTec public key to encrypt a facemap during the export process. ### Create a SCA session - [POST /v2/profiles/{profileId}/sca-sessions/authorise](https://docs.wise.com/api-reference/strong-customer-authentication/scasessioncreate.md): Manually triggers SCA, returning a one-time token along with a list of associated challenges. These challenges can be cleared with the verify endpoints. ## Transfer A transfer is a payment order to a [recipient account](/api-reference/recipient) based on a [quote](/api-reference/quote). Once created, a transfer usually needs to be funded within fourteen days. Otherwise, it will be automatically cancelled. There are 2 types of transfer resources: standard transfer resource and originator transfer resource. Please see below for differences between the two. Standard Transfer {% #standard-transfer .title-3 .m-t-5 %} The standard transfer object is returned by the [create transfer](/api-reference/transfer/transfercreate), [get transfer](/api-reference/transfer/transferget), [list transfers](/api-reference/transfer/transferlist), and [cancel transfer](/api-reference/transfer/transfercancel) endpoints. Originator Transfer {% #originator-transfer .title-3 .m-t-5 %} The originator transfer object is returned by the [create third party transfer](/api-reference/transfer/transferthirdpartycreate) and [get third party transfer](/api-reference/transfer/transferthirdpartyget) endpoints. It includes an additional `originator` data block with details about the payment originator. ### Create a transfer - [POST /v1/transfers](https://docs.wise.com/api-reference/transfer/transfercreate.md): Create a transfer to a recipient account based on a quote. Some fields are conditionally required depending on the currency route and transfer amount. Always call the transfer requirements endpoint to determine which fields are needed, and submit values accordingly. These requirements may change over time. #### Avoiding duplicate transfers The customerTransactionId field is used to avoid duplicate transfer requests. If your initial call to create a transfer fails (error or timeout), retry the call using the same customerTransactionId value. Subsequent retry messages are treated as repeat messages and will not create duplicate transfers. Use a sensible retry limit, ideally with a back-off approach. #### Payment Approvals {% admonition type="warning" %} Business Payment Approvals created on your wise.com settings page are not compatible with creating transfers over the API. {% /admonition %} If you use personal tokens and do not use client credentials, and if your business account has payment approvals, your application will receive this error when attempting to create a transfer: Quote cannot be accepted with this request due to missing approval. Consider removing the payment rule if you are going to use the API to create transfers. ### List transfers - [GET /v1/transfers](https://docs.wise.com/api-reference/transfer/transferlist.md): Get the list of transfers for a given user's profile (defaults to user's personal profile). You can add query parameters to specify user's profile (personal or business), time period and/or payment status. For example, you can query all failed payments created since last week, or all completed payments created since yesterday. ### Get a transfer by ID - [GET /v1/transfers/{transferId}](https://docs.wise.com/api-reference/transfer/transferget.md): Get transfer info by ID. To receive dynamic updates as the state of the transfer changes, see the webhooks documentation. ### Cancel a transfer - [PUT /v1/transfers/{transferId}/cancel](https://docs.wise.com/api-reference/transfer/transfercancel.md): Transfers may be cancelled up until the transfer has been processed and funds converted. Cancellation is final — it cannot be undone. {% admonition type="info" name="When can a transfer be cancelled?" %} A transfer can only be cancelled programmatically via the API if it meets all of the following criteria: - The transfer is not in funds_converted or later state. - There are no processing problems with the transfer. If the transfer does not meet these criteria, the API will return a 409 Conflict error with the code transfer.cancellation.not.allowed. For more information about transfer states, see Tracking Transfers. {% /admonition %} ### Validate transfer requirements - [POST /v1/transfer-requirements](https://docs.wise.com/api-reference/transfer/transferrequirementsvalidate.md): Exposes transfer-specific requirements based on the sender, quote, and target recipient account. Requirements vary by currency route, transfer amount, and regulatory region. For example, the maximum allowed length of reference text varies — the US payment system (ACH) supports 10 characters only, but transfers within Mexico allow up to 100 characters. Similarly, depending on the chosen currencies and the amount to be transferred, Wise may require additional details such as source of funds or transfer purpose. We highly recommend verifying transfer requirements before submitting any transfer to avoid delays caused by missing details. {% admonition type="success" name="Integration guide" %} See the Transfer Requirements guide for step-by-step integration instructions and a list of common requirement fields. {% /admonition %} ### Create a third party transfer - [POST /v2/profiles/{profileId}/third-party-transfers](https://docs.wise.com/api-reference/transfer/transferthirdpartycreate.md): Create a transfer on behalf of a third party. When creating a third party transfer: - The originator datablock is required. This details the ultimate sender of funds in the transfer. - Depending on the legal entity type of the originator (PRIVATE or BUSINESS), the required fields vary. - originalTransferId field must be used. This is your own ID for the transfer. You need to save the transfer ID for tracking its status later via webhooks. #### Avoiding duplicate transfers The originalTransferId field is used to avoid duplicate transfer requests. If your initial call fails (error or timeout), retry the call using the same originalTransferId value. Subsequent retry messages are treated as repeat messages and will not create duplicate transfers. ### Get a third party transfer by ID - [GET /v2/profiles/{profileId}/third-party-transfers/{transferId}](https://docs.wise.com/api-reference/transfer/transferthirdpartyget.md): Get third party transfer info by ID. To receive dynamic updates as the state of the transfer changes, see the webhooks documentation. ### Fund a transfer - [POST /v3/profiles/{profileId}/transfers/{transferId}/payments](https://docs.wise.com/api-reference/transfer/transferfund.md): {% admonition type="warning" %} This endpoint is SCA protected when it applies. If your profile is registered within the UK and/or EEA, SCA most likely applies to you. Please read more about implementing SCA. {% /admonition %} This API call is the final step for executing payouts when using a balance with Wise. Upon calling the endpoint, Wise will begin the processing of the transfer, depending on the status of funds. When using the transfer by transfer settlement model, the following funding type(s) must be used: - BALANCE — Funds are pulled from a multi-currency account held with Wise. - BANK_TRANSFER — Manually send funds from your business bank account to pay for any transfers. Only applicable when using the Batch Group API. When funding through the Bulk Settlement model, the following funding type(s) must be used: - TRUSTED_PRE_FUND_BULK — Funds for the transfer will be settled through a bulk payment at a later date. This method is not applicable for First Party partner account transfers. If funding from BALANCE, and your multi-currency account does not have the required funds to complete the action, then this call will fail with an "insufficient funds" error. Once funds are added and available, you must call this endpoint again. ### List completed payments - [GET /v1/transfers/{transferId}/payments](https://docs.wise.com/api-reference/transfer/transferpaymentslist.md): Fetch completed payments used to fund the transfer. In most cases there should only be a single payment associated with the transfer. There are rare occasions that a transfer can be funded with multiple payment methods and when this occurs the first completed payment method would be used to calculate the fees provided on the quote. ### Get payout information - [GET /v2/transfers/{transferId}/invoices/bankingpartner](https://docs.wise.com/api-reference/transfer/transferpayoutinfoget.md): Fetch banking reference information for transfers that are in outgoing_payment_sent status, enabling you to track transfers with the transfer recipient's bank. It may take up to 3 days to get the correct information through this endpoint, as some partners don't share the information until 3 days later. ### Get a transfer receipt - [GET /v1/transfers/{transferId}/receipt.pdf](https://docs.wise.com/api-reference/transfer/transferreceiptget.md): Download transfer confirmation receipt in PDF format for transfers that are in status outgoing_payment_sent. There's also the transfer state change webhook. {% admonition type="info" %} If you service US retail consumers you must use the US combined receipt endpoint instead. {% /admonition %} ### Get a US combined disclosure receipt - [GET /v1/transfers/{transferId}/us-combined-receipt.pdf](https://docs.wise.com/api-reference/transfer/transferuscombinedreceiptget.md): Download US combined receipt in PDF format for transfers that are in status incoming_payment_initiated and again when the status is updated to outgoing_payment_sent. ### Get a non objection certificate (INR) - [GET /v1/transfers/{transferId}/documents/noc](https://docs.wise.com/api-reference/transfer/transfernocget.md): Download transfer non objection certificate in PDF format for transfers that are in status outgoing_payment_sent. This document can be used to obtain a Foreign Inward Remittance Certificate (FIRC) from the bank that paid out the transfer. This is only applicable to INR payments with either a business sender or recipient. ### Get a third party transfer by ID (V1) (deprecated) - [GET /v1/profiles/{profileId}/third-party-transfers/{transferId}](https://docs.wise.com/api-reference/transfer/transferthirdpartygetv1.md): {% admonition type="warning" %} This endpoint is deprecated. Use Get a third party transfer by ID (V2) instead. {% /admonition %} Get third party transfer info by ID. To receive dynamic updates as the state of the transfer changes, see the webhooks documentation. ### Create a partner licence transfer (deprecated) - [POST /v1/profiles/{profileId}/partner-licence-transfers](https://docs.wise.com/api-reference/transfer/transferpartnerlicencecreate.md): {% admonition type="warning" name="Deprecated" %} This endpoint is deprecated and only maintained for existing legacy integrations. Do not use it for new integrations. Use Create a transfer or Create a third party transfer instead. {% /admonition %} This is similar to the Create a transfer endpoint, but the originator datablock is additionally required. You need to save the transfer ID for tracking its status later via webhooks. #### Avoiding duplicate transfers The customerTransactionId field is used to avoid duplicate transfer requests. If your initial call fails (error or timeout), retry the call using the same customerTransactionId value. Subsequent retry messages are treated as repeat messages and will not create duplicate transfers. ## User A User serves as the primary entity and can possess multiple Profiles to represent different contexts or settings. A User can have one personal Profile and multiple business Profiles. Each [Profile](/api-reference/profile) — whether personal or business — can have its own [multi-currency account](/api-reference/multi-currency-account), enabling transactions across various currencies. This hierarchical structure allows for flexible management of user settings and financial operations, accommodating both personal and business needs. ![User profile structure](/images/diagrams/user-profile-structure.svg) ### Retrieve current user by token - [GET /v1/me](https://docs.wise.com/api-reference/user/usergetbytoken.md): Get authenticated user details for the user's token submitted in the Authorization header. ### Retrieve a user by ID - [GET /v1/users/{userId}](https://docs.wise.com/api-reference/user/usergetbyid.md): Get authenticated user details by user ID. ### Create a user with a registration code - [POST /v1/user/signup/registration_code](https://docs.wise.com/api-reference/user/usercreate.md): Wise uses email address as unique identifier for users. If email is new (there is no active user already) then a new user will be created. When you are submitting an email which already exists amongst our users then you will get a warning that "You're already a member. Please login". If user already exists then you need to redirect to "Get user authorization" webpage. ### Check if user exists - [POST /v1/users/exists](https://docs.wise.com/api-reference/user/usercheckexists.md): Check if a user already exists by email. Wise uses email address as unique identifier for users. If email has already been used by a user, it cannot be reused to create a new user. Note that this uses a client-credentials-token and not a user access_token for authentication. ### Set a contact email address - [PUT /v1/users/{userId}/contact-email](https://docs.wise.com/api-reference/user/usercontactemailset.md): Sets a contact email address. The contact email address is used to send notifications to users who have been registered with a dummy email address. ### Retrieve a contact email address - [GET /v1/users/{userId}/contact-email](https://docs.wise.com/api-reference/user/usercontactemailget.md): Retrieves a contact email address. ## User Security {% admonition type="warning" %} These endpoints are deprecated. Please refer to [Strong Customer Authentication](/api-reference/strong-customer-authentication) to integrate with SCA. {% /admonition %} User security allows users to set up security-related protections over the API. ### Create PIN - [POST /v1/user/pin](https://docs.wise.com/api-reference/user-security/usersecuritypincreate.md): Create PIN for a user as a form of authentication. Can be used to verify pin when accessing a strongly protected endpoint via One Time Token Framework. The request and response are encrypted using the JOSE framework. Please refer to the JOSE JWE guide to understand how encryption and decryption work. ### Delete PIN - [DELETE /v1/users/{userId}/pin](https://docs.wise.com/api-reference/user-security/usersecuritypindelete.md): Remove the PIN from the user's account. {% admonition type="warning" %} This endpoint is restricted and requires both a client credentials token and additional access to use. Please speak with your implementation manager if you would like to use this API. {% /admonition %} ### Enrol FaceMap - [POST /v1/user/facemap/enrol](https://docs.wise.com/api-reference/user-security/usersecurityfacemapenrol.md): Facial biometric enrolment for Strong Customer Authentication (SCA). Can be used to verify facemap when accessing a strongly protected endpoint via One Time Token Framework. ### Delete FaceMap - [DELETE /v1/users/{userId}/facemap/enrol](https://docs.wise.com/api-reference/user-security/usersecurityfacemapdelete.md): Remove the FaceMap from the user's account. {% admonition type="warning" %} This endpoint is restricted and requires both a client credentials token and additional access to use. Please speak with your implementation manager if you would like to use this API. {% /admonition %} ### Create Device Fingerprint - [POST /v1/user/partner-device-fingerprints](https://docs.wise.com/api-reference/user-security/usersecuritydevicefingerprintcreate.md): A device fingerprint represents a string that identifies a unique device. This endpoint is used to register the fingerprint of the device as one of the allowed devices used during an One Time Token (OTT) challenge. This can be used to verify device fingerprint when clearing a OTT. The request and response are encrypted using the JOSE framework. Please refer to the JOSE JWE guide to understand how encryption and decryption work. ### List Device Fingerprints - [GET /v1/users/{userId}/partner-device-fingerprints](https://docs.wise.com/api-reference/user-security/usersecuritydevicefingerprintlist.md): Returns a list of device fingerprints created for this user. {% admonition type="warning" %} This endpoint is restricted and requires both a client credentials token and additional access to use. Please speak with your implementation manager if you would like to use this API. {% /admonition %} ### Delete Device Fingerprint - [DELETE /v1/users/{userId}/partner-device-fingerprints/{deviceFingerprintId}](https://docs.wise.com/api-reference/user-security/usersecuritydevicefingerprintdelete.md): Remove a specific device fingerprint from the allowed devices of a user. {% admonition type="warning" %} This endpoint is restricted and requires both a client credentials token and additional access to use. Please speak with your implementation manager if you would like to use this API. {% /admonition %} ### List Phone Numbers - [GET /v1/application/users/{userId}/phone-numbers](https://docs.wise.com/api-reference/user-security/usersecurityphonenumberlist.md): List verified phone numbers for a user. {% admonition type="warning" %} This endpoint is restricted and requires both a client credentials token and additional access to use. Please speak with your implementation manager if you would like to use this API. {% /admonition %} ### Create Phone Number - [POST /v1/application/users/{userId}/phone-numbers](https://docs.wise.com/api-reference/user-security/usersecurityphonenumbercreate.md): Create a verified phone number for a user. {% admonition type="warning" %} This endpoint is restricted and requires both a client credentials token and additional access to use. Please speak with your implementation manager if you would like to use this API. {% /admonition %} ### Update Phone Number - [PUT /v1/application/users/{userId}/phone-numbers/{phoneNumberId}](https://docs.wise.com/api-reference/user-security/usersecurityphonenumberupdate.md): Update a verified phone number for a user. {% admonition type="warning" %} This endpoint is restricted and requires both a client credentials token and additional access to use. Please speak with your implementation manager if you would like to use this API. {% /admonition %} ### Delete Phone Number - [DELETE /v1/application/users/{userId}/phone-numbers/{phoneNumberId}](https://docs.wise.com/api-reference/user-security/usersecurityphonenumberdelete.md): Delete a verified phone number for a user. {% admonition type="warning" %} This endpoint is restricted and requires both a client credentials token and additional access to use. Please speak with your implementation manager if you would like to use this API. {% /admonition %} ## Webhook Manage webhook subscriptions at both the application and profile level. Create, list, retrieve, and delete subscriptions, as well as test your webhook endpoints. For more information on creating and managing webhooks, and specific event types, see [Webhooks & Notifications](/guides/developer/webhooks). ### Create Application Webhook Subscription - [POST /v3/applications/{clientKey}/subscriptions](https://docs.wise.com/api-reference/webhook/webhookapplicationsubscriptioncreate.md): Create a webhook subscription at the application level. clientKey can be received upon obtaining client credentials from our tech support. ### List Application Webhook Subscriptions - [GET /v3/applications/{clientKey}/subscriptions](https://docs.wise.com/api-reference/webhook/webhookapplicationsubscriptionlist.md): List all webhook subscriptions for your application. ### Get Application Webhook Subscription - [GET /v3/applications/{clientKey}/subscriptions/{subscriptionId}](https://docs.wise.com/api-reference/webhook/webhookapplicationsubscriptionget.md): Retrieve an application webhook subscription by its identifier. ### Delete Application Webhook Subscription - [DELETE /v3/applications/{clientKey}/subscriptions/{subscriptionId}](https://docs.wise.com/api-reference/webhook/webhookapplicationsubscriptiondelete.md): Delete an application webhook subscription by its identifier. ### Test Application Webhook Subscription - [POST /v3/applications/{clientKey}/subscriptions/{subscriptionId}/test-notifications](https://docs.wise.com/api-reference/webhook/webhookapplicationsubscriptiontest.md): Generate test notifications for an existing application subscription. Test notifications will have the correct structure for their source subscription's event type and version, and will contain "dummy" data. These data include random UUIDs, entity IDs of zero, current dates and times, and hard-coded status codes. Test notifications are delivered with the usual notification HTTP request headers, including a unique delivery ID for the notification, and a "test notification" flag set to true. You can check for the presence of this test flag to determine that an incoming notification is a test notification which should not be processed as real data. See the section Event HTTP requests for more information on request headers. When test notifications are created with the API, they are queued for sending in the same way as non-test notifications. This means that there may be some delay in notification delivery, and delivery failures will result in attempts to redeliver the notification later. The API returns the delivery IDs of the notifications that have been successfully queued for sending, which can be correlated with the delivery ID header values for notifications you later receive. {% admonition type="info" %} This test notification API is only available for application-based subscriptions. Profile-based subscriptions do not currently support this testing feature. {% /admonition %} ### Create Profile Webhook Subscription - [POST /v3/profiles/{profileId}/subscriptions](https://docs.wise.com/api-reference/webhook/webhookprofilesubscriptioncreate.md): Create a webhook subscription at the profile level. ### List Profile Webhook Subscriptions - [GET /v3/profiles/{profileId}/subscriptions](https://docs.wise.com/api-reference/webhook/webhookprofilesubscriptionlist.md): List all webhook subscriptions for a profile. ### Get Profile Webhook Subscription - [GET /v3/profiles/{profileId}/subscriptions/{subscriptionId}](https://docs.wise.com/api-reference/webhook/webhookprofilesubscriptionget.md): Retrieve a profile webhook subscription by its identifier. ### Delete Profile Webhook Subscription - [DELETE /v3/profiles/{profileId}/subscriptions/{subscriptionId}](https://docs.wise.com/api-reference/webhook/webhookprofilesubscriptiondelete.md): Delete a profile webhook subscription by its identifier.