Skip to main content
POST
Verify a SEPA payee
Authentication: API key OAuth 2.0
Scope: payment.write Sensitive
Related guide: Verification of Payee
You can also use the Sandbox environment to test the endpoint with mocked IBANs.
Token requirementThe proof_token included in the response is required for initiating a SEPA transfer and will be valid regardless of the verification result. Please review the response, results that are not a MATCH_RESULT_MATCH may indicate a transfer will be sent to a wrong beneficiary.
Rate limitsA verification is only intended to be used before initiating a SEPA transfer. Rate limits will apply to verifications that are not followed by a transfer initiation. Please perform each individual verification before its corresponding transfer.
Error handling — responding bank errors vs verification resultsIt is important to distinguish between verification results (HTTP 200) and error responses (HTTP 4xx/5xx):
  • A 200 response with MATCH_RESULT_NOT_POSSIBLE means the responding bank was successfully contacted but could not perform the name verification (e.g., the account type does not support Verification of Payee). A proof_token is included.
  • A 400 error with codes like BAD_REQUEST_ERROR_RESPONDING_BANK_NOT_AVAILABLE, BAD_REQUEST_ERROR_5XX_RESPONDING_BANK, or BAD_REQUEST_ERROR_RESPONDING_BANK_INVALID_RESPONSE means the responding bank returned an unexpected response. A proof_token is included in the error meta.
  • A 503 error with BAD_GATEWAY_ERROR_RESPONDING_BANK or GATEWAY_TIMEOUT_ERROR_RESPONDING_BANK means the responding bank could not be reached or returned a server error. This is a transient issue — retry after a short delay. A proof_token is included in the error meta.
The proof_token provided in error responses allows you to proceed with the transfer if needed, but the payee name was not verified. See why bank errors are not match results.

Authorizations

Authorization
string
header
required

Bearer authorization header: Bearer <token>, where <token> is the access token received from the authorization server at the end of the OAuth 2.0 flow.

Headers

X-Qonto-Staging-Token
string

Required only for Sandbox API requests; to get one, please sign up to the Developer Portal.

Body

application/json
iban
string
required

IBAN of the beneficiary account to be verified

Pattern: ^[A-Z]{2}[0-9]{2}[A-Z0-9]{4}[0-9]{7}([A-Z0-9]?){0,16}$
Example:

"FR7616958000014849440866435"

beneficiary_name
string
required

Name of the beneficiary to verify against the account

Required string length: 1 - 140
Example:

"John Doe"

Response

Verification completed successfully

match_result
enum<string>

Result of the payee verification

Available options:
MATCH_RESULT_MATCH,
MATCH_RESULT_NO_MATCH,
MATCH_RESULT_CLOSE_MATCH,
MATCH_RESULT_NOT_POSSIBLE,
MATCH_RESULT_UNSPECIFIED
Example:

"MATCH_RESULT_MATCH"

matched_name
string | null

The actual name associated with the account (present for close matches)

Example:

"Jon Jones"

proof_token
object

Token ensuring verification of payee was performed for the beneficiary in the request. This token must be used to initiate a transfer to this beneficiary, validation will fail otherwise. The token can be used regardless of the VOP match result.