Approve SEPA DD mandate
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.
Payloaddomain.ApproveTokenRequest
Properties
|
|||
Property | Type | Required | Details |
---|---|---|---|
mandateSignatureDate | string (8) | no | read close |
close
DescriptionThe date when the mandate was signed
Format: YYYYMMDD |
|||
mandateSignaturePlace | string (51) | no | read close |
close
DescriptionThe city where the mandate was signed
|
|||
mandateSigned | boolean | no | read close |
close
Description
|
Request example
This scenario you will probably use the most
-
// Assigning literals to pointer variables directly is not supported. // The below code uses helper functions connectsdk.NewBool and connectsdk.NewString to overcome this issue. // These helper functions are provided by the SDK's root package. // http://stackoverflow.com/a/30716481 lists a few more alternatives. var body domain.ApproveTokenRequest body.MandateSignatureDate = connectsdk.NewString("20150201") body.MandateSignaturePlace = connectsdk.NewString("Monument Valley") body.MandateSigned = connectsdk.NewBool(true) err := client.V1().Merchant("merchantId").Tokens().Approvesepadirectdebit("tokenId", body, nil)
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 requestdomain.ErrorResponse
Properties
|
|||
Property | Type | Required | Details |
---|---|---|---|
errorId | string | yes | read close |
close
DescriptionUnique reference, for debugging purposes, of this error response
|
|||
array of object | yes | read close | |
close
DescriptionList of one or more errors
|
|||
object | no | read close | |
close
DescriptionContains detailed information on one single error.
|
|||
category | string | no | read close |
close
DescriptionCategory the error belongs to. The category should give an indication of the type of error you are dealing with.
Possible values:
|
|||
code | string | yes | read close |
close
DescriptionError code
|
|||
httpStatusCode | integer | no | read close |
close
DescriptionHTTP status code for this error that can be used to determine the type of error
|
|||
id | string | no | read close |
close
DescriptionID of the error. This is a short human-readable message that briefly describes the error.
|
|||
message | string | no | read close |
close
DescriptionHuman-readable error message that is not meant to be relayed to customer as it might tip off people who are trying to commit fraud
|
|||
propertyName | string | no | read close |
close
DescriptionReturned 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:
|
|||
requestId | string | no | read close |
close
DescriptionID of the request that can be used for debugging purposes
|
Response example
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" } ] }