This site requires javascript to be enabled.

  • Search AI-powered
    Search results are AI-generated and are not guaranteed to be accurate, complete, or up-to-date. They are not a substitute for legal or professional advice. Refer to our terms of use for more details.
    Search AI-powered

Results for

xxx

Approve SEPA DD mandate

POST https://{domainname}/v1/{merchantId}/tokens/{tokenId}/approvesepadirectdebit

Tokens

Using our tokenization service you can tokenize re-usable payment data like card data, bank account data including Direct Debit Mandates and PayPal BillingAgreementIDs. The main purpose for tokens is re-use of payment details. The additional benefit is that you do not need to store any sensitive payment details on your server, while still having the benefit to be able to re-use them. This allows you to process recurring card transactions without actually having access to the real card data.

Tokens can be used for two types of transactions:

  • Recurring: Automatically charging your consumer in a regular, e.g. monthly, time frame;
  • One-off: Charge the consumer without the consumer having to re-enter all of their payment details.

The second scenario can be used to facilitate a one-click checkout solution, that would still allow the consumer to enter only their CVV value for a card transaction. CVV values can't be tokenized as they are not allowed to be stored at all.

Besides the re-use of payment data, tokens have one other major use-case: Direct Debit Mandates. Especially SEPA Direct Debit transactions require that the mandate for the transactions is managed through a token with an associated mandate. Mandates are created in one go with the token, but can have a state that requires that they are approved before they can be used. As the mandate process is in most cases an offline process the approval will allow you to set the location and date where and when the mandate was signed by the consumer. Without an approved SEPA mandate you will not be able to process any payments regarding this mandate.

Request

Direct Debit mandates are managed as part of the token. The mandate holds all the required data to process the direct debit transaction. By referring to the token containing the mandate you can create new transactions for each billing run (or debit). Before you can do this the consumer needs to have signed the mandate and you will need to have provided us with the details on this approval through this API call. To approve a mandate you will need to provide us with information on when and where the mandate was signed. You also need to explicitly state that the mandate was indeed signed. Without an approved SEPA mandate you will not be able to process any payments regarding this mandate.

PayloadApproveTokenRequest

Properties
Property Type Required Details
close

Description

The date when the mandate was signed
Format: YYYYMMDD
close

Description

The city where the mandate was signed
close

Description

  • true = Mandate is signed
  • false = Mandate is not signed
Note: Default value if not provided is false.

Request example

SDK: JSON

This scenario you will probably use the most

  • {
    "mandateSignaturePlace" : "Monument Valley",
    "mandateSignatureDate" : "20150201",
    "mandateSigned" : true
}

Responses

Please find below an overview of the possible responses.

Response 204 - No content

A 204 response denotes that the token was successfully approved.

Response 400 - Bad requestErrorResponse

Properties
Property Type Required Details
close

Description

Unique reference, for debugging purposes, of this error response
close

Description

List of one or more errors
close

Description

Contains detailed information on one single error.
  • SDK Object type
    APIError
close

Description

Category the error belongs to. The category should give an indication of the type of error you are dealing with. Possible values:
  • CONNECT_PLATFORM_ERROR - indicating that a functional error has occurred in the Connect platform.
  • PAYMENT_PLATFORM_ERROR - indicating that a functional error has occurred in the Payment platform.
  • IO_ERROR - indicating that a technical error has occurred within the Connect platform or between Connect and any of the payment platforms or third party systems.
close

Description

Error code
close

Description

HTTP status code for this error that can be used to determine the type of error
close

Description

ID of the error. This is a short human-readable message that briefly describes the error.
close

Description

Human-readable error message that is not meant to be relayed to customer as it might tip off people who are trying to commit fraud
close

Description

Returned only if the error relates to a value that was missing or incorrect.
Contains a location path to the value as a JSonata query.
Some common examples:
  • a.b selects the value of property b of root property a,
  • a[1] selects the first element of the array in root property a,
  • a[b='some value'] selects all elements of the array in root property a that have a property b with value 'some value'.
close

Description

ID of the request that can be used for debugging purposes

Response example

SDK: JSON

This scenario you will probably use the most

  • {
    "errorId" : "15eabcd5-30b3-479b-ae03-67bb351c07e6-00000092",
    "errors" : [
        {
            "code" : "20000000",
            "propertyName" : "bankAccountBban.accountNumber",
            "message" : "PARAMETER_NOT_FOUND_IN_REQUEST"
        }
    ]
}