API Manual Contact details

Transcription

API Manual
Version: 2.14
Contact details
Simon Carmiggeltstraat 6-50
1011 DJ Amsterdam
P.O. Box 10095
1001 EB Amsterdam
The Netherlands
T +31 20 240 1240
E [email protected]
Table of Contents
1. Introduction...............................................................................................................................................................................................................................................................................................................................................
6
1.1. SOAP API............................................................................................................................................................................................................................................................................................................................7
1.2. REST API............................................................................................................................................................................................................................................................................................................................7
1.2.1. General Remarks On HTTP Name/Value Pair Communication................................................................................................................................................................................7
1.3. Security (Authentication).........................................................................................................................................................................................................................................................................................
8
2. Submitting API Payments..................................................................................................................................................................................................................................................................................................................9
2.1. Payment Fields..............................................................................................................................................................................................................................................................................................................
9
2.1.1. General Payment Fields..................................................................................................................................................................................................................................................................
9
2.1.2. Card Payment Specifc Fields....................................................................................................................................................................................................................................................10
2.1.3. Payment Response Fields...........................................................................................................................................................................................................................................................10
2.2. Submitting API Modifcation Requests.........................................................................................................................................................................................................................................................11
2.3. Client-Side Encryption (CSE) (optional).......................................................................................................................................................................................................................................................
11
2.3.1. How Does It Work?..........................................................................................................................................................................................................................................................................11
2.3.2. Additional Payment Fields.........................................................................................................................................................................................................................................................
12
2.3.3. Where Can I Find My Public key?............................................................................................................................................................................................................................................
12
2.3.4. Is CSE Secure?...................................................................................................................................................................................................................................................................................12
2.3.5. Main Benefts.....................................................................................................................................................................................................................................................................................
13
2.4. 3-D Secure.....................................................................................................................................................................................................................................................................................................................13
2.5. AVS.....................................................................................................................................................................................................................................................................................................................................15
2.6. Testing AVS and CVC/CVV Results....................................................................................................................................................................................................................................................................
15
2.6.1. Testing AVS Results.........................................................................................................................................................................................................................................................................15
2.6.2. Test CVC/CVV Results.....................................................................................................................................................................................................................................................................16
2.7. Card Verifcation/Dynamic Zero Value Auth................................................................................................................................................................................................................................................16
2.8. Installments..................................................................................................................................................................................................................................................................................................................17
2.9. Additional Payment Response Data...............................................................................................................................................................................................................................................................
17
3. Idempotency In The Adyen API...................................................................................................................................................................................................................................................................................................
18
3.1. Idempotency Implementation...........................................................................................................................................................................................................................................................................
18
3.2. Retrying transactions and Idempotency......................................................................................................................................................................................................................................................19
3.2.1. Refused Transactions.....................................................................................................................................................................................................................................................................19
3.2.2. Transient Errors.................................................................................................................................................................................................................................................................................19
4. One-Click Payments...........................................................................................................................................................................................................................................................................................................................20
4.1. The Initial Payment..................................................................................................................................................................................................................................................................................................20
4.2. Submitting A One-Click Payment.....................................................................................................................................................................................................................................................................20
5. Card Deposit (CFT).............................................................................................................................................................................................................................................................................................................................21
5.1. Card Deposit Using An Existing Transaction.............................................................................................................................................................................................................................................
21
5.2. Directly Depositing Funds On A Card............................................................................................................................................................................................................................................................
21
5.3. CFT Notifcations.......................................................................................................................................................................................................................................................................................................
22
6. Direct Debit Payments.....................................................................................................................................................................................................................................................................................................................23
6.1. US ACH Payments......................................................................................................................................................................................................................................................................................................
23
6.1.1. ACH Transaction Types..................................................................................................................................................................................................................................................................
23
6.1.2. ACH Response....................................................................................................................................................................................................................................................................................23
6.1.3. ACH Chargebacks.............................................................................................................................................................................................................................................................................23
6.2. SEPA Direct Debits....................................................................................................................................................................................................................................................................................................
24
6.2.1. One-off SDD Payment Requests.............................................................................................................................................................................................................................................24
6.2.2. Recurring SDD Payment Requests.........................................................................................................................................................................................................................................24
6.2.3. SDD Notifcations............................................................................................................................................................................................................................................................................
25
2 / 68
API Manual
6.2.4. SDD Settlement Timeline...........................................................................................................................................................................................................................................................
26
6.2.5. SDD Chargebacks.............................................................................................................................................................................................................................................................................27
6.3. ELV Payments – deprecated 1st August 2014..........................................................................................................................................................................................................................................
27
6.4. Dutch Incasso Payments – deprecated 1st August 2014..................................................................................................................................................................................................................28
6.4.1. Incasso Response.............................................................................................................................................................................................................................................................................
28
6.4.2. Incasso Chargebacks......................................................................................................................................................................................................................................................................28
6.4.3. Incasso Statement Text................................................................................................................................................................................................................................................................29
6.4.4. Incasso Legal Requirements......................................................................................................................................................................................................................................................29
7. Boleto Bancário....................................................................................................................................................................................................................................................................................................................................30
7.1. Boleto Notifcations..................................................................................................................................................................................................................................................................................................
30
7.2. Important Information Regarding Storage Of The Boleto PDF......................................................................................................................................................................................................
31
8. Notifcations...........................................................................................................................................................................................................................................................................................................................................32
8.1. Notifcation Message Fields................................................................................................................................................................................................................................................................................32
8.2. Accepting Notifcations..........................................................................................................................................................................................................................................................................................34
9. API Fault Codes....................................................................................................................................................................................................................................................................................................................................35
Appendix A: TEST and LIVE URLs...................................................................................................................................................................................................................................................................................................
36
Appendix B: SOAP API Payment Request and Response...................................................................................................................................................................................................................................................37
Appendix C: REST API Payment Request and Response...................................................................................................................................................................................................................................................
38
Appendix D: CSE Source Libraries Used.....................................................................................................................................................................................................................................................................................
39
Appendix F: Integration Example – CSE....................................................................................................................................................................................................................................................................................42
Appendix G: Integration Example – Server Side (SOAP)..................................................................................................................................................................................................................................................
43
Appendix H: Integration Example – Server Side (REST with cURL)..........................................................................................................................................................................................................................44
Appendix I: Authorise3d Request...................................................................................................................................................................................................................................................................................................
46
Appendix J: Payment Request with Installments..................................................................................................................................................................................................................................................................
47
Appendix K: CVC/CVV and AVS Result Values..........................................................................................................................................................................................................................................................................
48
Appendix L: ACH Payment Request...............................................................................................................................................................................................................................................................................................49
Appendix M: SEPA Direct Debit One-off Payment Request and Response............................................................................................................................................................................................................50
Appendix N: SEPA Direct Debit Recurring Payment Request.........................................................................................................................................................................................................................................52
Appendix O: Incasso Payment Request.......................................................................................................................................................................................................................................................................................53
Appendix P: Boleto SOAP API Payment Request and Response...................................................................................................................................................................................................................................54
Appendix Q: Boleto REST API Payment Request and Response...................................................................................................................................................................................................................................56
Appendix R: Sample Boleto Forms................................................................................................................................................................................................................................................................................................57
Appendix S: SOAP Notifcation Request and Response.....................................................................................................................................................................................................................................................
59
Appendix T: REST Notifcation Request and Response......................................................................................................................................................................................................................................................61
Appendix U: Fault Codes.....................................................................................................................................................................................................................................................................................................................
62
3 / 68
API Manual
ADYEN CONFIDENTIAL INFORMATION
Copyright (c) Adyen B.V. 2014
Changelog
Version
Date
Changes
2.14
2014-08-28
• Added installments WSDL to Appendix A
• Added code for inserting line breaks to section 7 and updated examples in
Appendices P and Q
• Corrected typo in REST example of Appendix J
2.13
2014-04-30
• Updated Introduction to include PCI compliance section
• Added Transient errors and Idempotency section
• Updated authorise REST API examples
2.12
2014-01-15
•
•
•
•
2.11
2013-11-27
• Added note about testing AVS results
2.10
2013-11-22
• Added additional information regarding response codes to the AVS section
2.00
2013-11-14
• Combined SOAP and REST manuals
• Added Client Side Encryption
• Updated document to conform to Adyen brand guidelines
1.39
2013-09-13
• Added card verifcation and idempotency documentation
• Moved ELV to direct debit chapter
• Removed deprecated iDeal API
1.38
2013-03-18
• Added note about correct XML for SOAP Payment Request with installments
1.37
2012-11-12
• Added Received as possible responseCode
1.36
2012-10-19
• Added additional AVS result codes
1.35
2011-12-15
• Added information about not using LATEST with ONECLICK
1.34
2011-08-31
• Added API Payment Response
1.33
2011-02-16
• Added details about new selectedBrand parameter
1.32
2010-12-30
• Added ACH US direct debits
1.31
2010-12-21
• Added section about Installments
1.30
2010-12-03
• Added general Tips and Warnings
1.21
2010-07-16
• Added changelog and audience sections
• Manual reviewed for English and layout consistency
4 / 68
API Manual
Added note about testing CVC/CVV results
Added SEPA DD section
Added note on submitting amount value
Updated installments appendix
Audience
This is a technical manual aimed at IT personnel involved in integrating merchants' systems with those at Adyen.
The latest version of this document is available here:
https://support.adyen.com/links/documentation
General Tips/Warnings
Defensive Programming
Adyen strongly recommends the use of “defensive programming” when integrating with the Adyen Services. This implies
that automated decisions programmed into your systems should be defaulted to non-delivery of products and services. In
other words, program your systems to only deliver products and/or services after receiving an explicit authorisation of the
requested payment and NOT to deliver in situations where an explicit rejection is not received.
Feedback
You can provide feedback about this document by sending an email to the following address:
[email protected]
We appreciate your comments.
5 / 68
API Manual
1. Introduction
The purpose of this manual is to provide you with the ability to submit payments to the Adyen Payment System using an
API rather than the Hosted Payment Pages (HPP). Due to strict industry regulations the API is only available to merchants
who have full Payment Card Industry Data Security Standard (PCI DSS)1 compliance and fall into either the Level 1 or Level
2 categories. Furthermore, certain implementations of the API may require that you process minimum annual transaction
volumes. Please contact an Adyen sales representative for more information regarding the API and transaction volume
requirements.
While there are signifcant benefts to using the HPP rather than an API there are some situations in which it makes sense
for you to capture the payment details and use an API to submit these to Adyen. If you do not have full PCI DSS
compliance Adyen also ofers the ability to process payments using Client-Side Encryption, this is covered in more detail in
section 2.3.
In the following sections we will cover how you can submit payments to our platform using either Adyen's SOAP or REST
APIs. Details on how to submit modifcation requests is covered in the Adyen Merchant Integration Manual, this can be
found here:
Please note that the ability to process API payments or Client-Side Encryption is not enabled by default, please contact the
Adyen Support Team ([email protected]) if you would like to have this functionality enabled for you.
It is important to respect the DNS Time-To-Live (TTL) when communicating with Adyen. Some frameworks, Java in
particular, cache DNS lookups by default. Adyen routinely changes their DNS confguration and, if your implementation
caches the DNS lookup, your ability to submit modifcations and/or payments may be impacted.
This document is an addendum to the Adyen Merchant Integration Manual and will reference, without citation, concepts
explained there.
Adyen has code samples in various programming languages available for your reference; these can be found here:
https://github.com/adyenpayments
1Please see http://en.wikipedia.org/wiki/PCI_DSS for more information.
6 / 68
API Manual
1.1. SOAP API
SOAP is a communication protocol between two web services that uses XML for its message format. While you are free to
choose your preferred method of integration, SOAP/REST., in most cases we recommend that you implement a SOAP
integration to Adyen; SOAP implementations automatically handle a number of edge cases around encoding and
validation that will result in a more robust integration.
SOAP is also benefcial for high volume merchants particularly with regards to notifcations; if there are many pending
notifcations, the SOAP format allows Adyen to transfer multiple notifcations in a single message. As such, when
compared to REST messages, SOAP notifcations reduce the number of requests and improve throughput. Please refer to
section 8 for more details regarding notifcation processing.
1.2. REST API
Representational State Transfer (REST) is an architecture style for designing networked applications. The idea being that,
rather than using complex mechanisms such as CORBA, RPC or SOAP to connect machines, simple HTTP with name/value
pairs is used to make calls between machines, in much the same way that web browsers transfer requests between the
user and a web server. For example, a URL with the possibility of diferent parameters.
https://www.google.com/search?q=adyen
•
https:// indicates the secure HTTP protocol variant
•
www.google.com/search is the address of the platform/service
•
?q=adyen is a variable Name (q) / Value (adyen) pair that lets the service know information about adyen needs
to be queried and returned to the requesting service
An important component of REST is that it is stateless in nature. Each request from client to server must contain all of the
information necessary to understand the request, and cannot take advantage of any stored context on the server. Session
state is therefore kept entirely to the client.
1.2.1.
General Remarks On HTTP Name/Value Pair Communication
The Adyen APIs are mapped from the SOAP felds to REST Name/Value pairs. Adyen provides an easy testing option via a
regular web browser showing a default form for the variables. Please refer to Appendix A for the URL of the HTTP
adapter.
The following screenshots show how it is easy to make test payments.
1.
When accessing the HTTP Adapter URL in a browser you will be prompted to log in:
2.
Select the Adyen API function that you want to test/explore:
7 / 68
API Manual
3.
Insert
the payment
variables, including your specifc account details and the relevant felds for the transaction type and click the
submit button at the bottom of the page:
4.
The browser communicates the values as HTTP Name/Value pairs and the response to the request is displayed
in the browser:
1.3.
Security (Authentication)
To submit authorisation messages you must supply authentication credentials (username/password). This will be
confgured in the library that you use to communicate the server-to-server request, or response, to the Adyen platform.
The username is ws@Company.[YourCompanyAccount] and you set the password for this user in the Adyen Customer Area
8 / 68
API Manual
(CA) under “Settings” → “Users”.
9 / 68
API Manual
2. Submitting API Payments
SOAP API payments are submitted using the authorise action2. We will explain a simple credit card submission and in
subsequent sections we will show you how to implement “Verifed by VISA / MasterCard SecureCode™” (3-D Secure) and
Direct Debits.
2.1. Payment Fields 3
2.1.1.
General Payment Fields
•
merchantAccount
The merchant account for which you want to process the payment.
•
amount
A container for the data concerning the amount to be authorised. This should contain the following items:
•
currency
The three character ISO currency code.
•
value
The paymentAmount of the transaction.
Please note, the transaction amount should be provided in minor units according to ISO standards;
some currencies don't have decimal points, such as JPY, and some have 3 decimal points, such as BHD.
For example, 10 GBP would be submitted with a value of “1000” and 10 JPY would be submitted as
“10”.
•
reference
This is your reference for this payment, it will be used in all communication to you regarding the status of the
payment. We recommend using a unique value per payment but this is not a requirement. If you need to provide
multiple references for a transaction you may use this feld to submit them with the transaction, separating each
with “-”.
This feld has a maximum of 80 characters.
•
shopperIP (recommended)
The IP address of the shopper. We recommend that you provide this data, as it is used in a number of risk
checks, for example, number of payment attempts, location based checks.
•
shopperEmail (recommended)
The shopper's email address. We recommend that you provide this data, as it is used in a velocity fraud check.
Please note, this feld is required for Recurring payments.
•
shopperReference (recommended)
An ID that uniquely identifes the shopper, such as a customer id in a shopping cart system. We recommend that
you provide this data, as it is used in a velocity fraud check and is the key for recurring payments.
Please note, this feld is required for Recurring payments.
2
3
•
fraudOfset (optional)
An integer that is added to the normal fraud score. The value can be either positive or negative.
•
selectedBrand (optional)
Used with some payment methods to indicate how it should be processed. For the MisterCash payment method
it can be set to maestro (default) to be processed like a Maestro card or bcmc to be processed as a MisterCash
card.
The URLs are provided in Appendix A
Please refer to “Explanation of the Session Fields” section in the Adyen Merchant Integration Manual for more information
regarding each of the felds.
10 / 68
API Manual
When comparing the SOAP felds and HTTP felds they are exactly the same. Typically it is just one feld with the same
name, but more complex structures like the amount will be rendered in two individual felds:
SOAP representation of an amount:
<amount xmlns="http://payment.services.adyen.com">
<currency xmlns="http://common.services.adyen.com">EUR</currency>
<value xmlns="http://common.services.adyen.com">500</value>
</amount>
REST representation of an amount:
paymentRequest.amount.currency=EUR&paymentRequest.amount.value=500
2.1.2.
•
Card Payment Specifc Fields
card
A container for credit card data, this object should not be populated when using Client-Side Encryption. This
should contain the following items:
2.1.3.
•
expiryMonth
The expiration date's month written as a 2-digit string, padded with 0 if required. For example, 03 or 12.
•
expiryYear
The expiration date's year written as in full. For example, 2016.
•
holderName
The card holder's name, as embossed on the card.
•
number
The card number.
•
cvc
The card validation code. This is the the CVC2 code (for MasterCard), CVV2 (for Visa) or CID (for
American Express).
•
issueNumber (Maestro UK / Solo only)
This feld is no longer in use.
•
startMonth (Maestro UK / Solo only)
•
startYear (Maestro UK / Solo only)
Payment Response Fields
If the message passes validation a risk analysis will be done and, depending on the outcome, an authorisation will be
attempted. You will receive a response with the following felds:
•
pspReference
This is Adyen's unique reference that is associated with the payment. This is guaranteed to be globally unique
and is used when communicating with us about this payment.
•
resultCode
The result of the payment. The possible values are Authorised, Refused, Error or Received (as with a Dutch Direct
Debit).
•
authCode
The authorisation code if the payment was successful. Blank otherwise.
•
refusalReason
Adyen's mapped refusal reason, populated if the payment was refused.
Please refer to Appendix B and Appendix C for examples of SOAP and REST API requests and responses.
11 / 68
API Manual
2.2. Submitting API Modifcation Requests
In addition to being able to perform modifcations via the Adyen Customer Area (CA), you may also use the API to initiate
your modifcation requests. Modifcations are submitted using the same API, URL, WSDL, username and password as
used for authorisations but using the modifcation specifc action.
Please refer to the Adyen Merchant Integration Manual for details:
2.3. Client-Side Encryption (CSE) (optional)
Merchants that require more stringent security protocols or do not want the additional overhead of managing their PCI
compliance, may decide to implement Client-Side Encryption (CSE). This is particularly useful for Mobile payment fows
where only cards are being ofered, as it may result in faster load times and an overall improvement to the shopper fow.
The Adyen Hosted Payment Page (HPP) provides the most comprehensive level of PCI compliancy and you do not have
any PCI obligations. Using CSE reduces your PCI scope when compared to implementing the API without encryption, as
Adyen bears the PCI burden on your behalf.
If you would like to implement CSE, please provide the completed PCI Self Assessment Questionnaire (SAQ) A to the
Adyen Support Team ([email protected]). The form can be found here:
https://www.pcisecuritystandards.org/security_standards/documents.php?category=saqs
Transactions that are submitted using Client-Side Encrypted card details follow the same process as a regular
authorisation request. However, instead of the card object, the encrypted data is sent in the additional data felds
described in section 2.3.2.
Adyen has built some code samples for your review, these are available here:
https://github.com/adyenpayments/client-side-encryption
2.3.1.
How Does It Work?
To implement CSE, you will need to follow this high level process:
1.
Build and host the credit card payment form on your servers.
2.
Ensure that the card felds have the attribute “data-encrypted-name” instead of “name”; the use of “name” may
result in the raw card data to be posted to your servers.
3.
Include the “adyen.encrypt.min.js” Client Encryption library.
4.
Set the Adyen public key and tie the Adyen library to your form.
The Client Encryption library will:
1.
Intercept the form submission event before it hits your server.
2.
Encrypt the card felds in-browser using a per transaction unique AES key.
3.
Encrypt the unique AES key with your RSA public key, Adyen retains its private counterpart.
4.
Send the encrypted data, containing the card and encrypted AES key, with the other felds in the form via the
server-to-server API.
Please note, the encrypted data must not be stored on your servers or be available in your logs as this would be a
violation of PCI regulations.
12 / 68
API Manual
2.3.2.
Additional Payment Fields
There are two additional felds that will need to be passed in the authorisation request:
•
generationtime
This feld is used to determine the validity of the payment request, any transactions submitted after 24 hours of
this time will be refused. The format for this feld is the ISO 8601 format: YYYY-MM-DDTHH:mm:ss.sssZ . For
example, “2013-11-15T13:42:40.428Z”. This must be generated server-side as the client (browser) may not have
its system clock synchronised which could cause the payment to fail.
•
adyen-encrypted-data
This feld is used to transmit the encrypted to Adyen.
Please refer to Appendix G for a SOAP CSE example and to Appendix H for a REST CSE example.
2.3.3.
Where Can I Find My Public key?
The public key is tied to the WebService user you will be using to submit the API payment request, as described in section
1.3. If a key has not previously been generated, you will see an option to “Generate” the key. The generated key is preformatted for easy insertion into your page.
2.3.4.
Is CSE Secure?
The CSE solution uses only PCI/NIST approved cryptographic algorithms. The RSA key is 2048 bits and is unique to your
user account. Per transaction the client will generate a unique AES (256bit) key which is used in CCM mode for both
encryption and authentication.
•
The Public Key (RSA) can be downloaded from the Adyen CA.
•
The Secret Key (RSA) is only known to Adyen and stored in encrypted form on Adyen's servers.
•
All card data is End-To-End encrypted and is never visible to merchant.
•
The payment authorisation is done over the server-to-server Adyen API using the encrypted card.
•
The encrypted data is only valid for a period of 24 hours and tied to your public key. It is of no use outside of this
context.
13 / 68
API Manual
2.3.5.
Main Benefts
•
The credit card data is never readable to you.
•
Stateless, synchronous processing; the solution does not rely on a session token.
•
Uses the current API therefore all features are available:
◦
3D Secure.
◦
Recurring.
◦
Installments.
◦
Airline / Level 3 Data.
◦
Risk/Fraud Detection.
2.4. 3-D Secure
3-D Secure (Verifed by VISA / MasterCard SecureCode™) is an additional authentication protocol that involves the shopper
being redirected to their card issuer where they authenticate themselves before the payment can proceed to an
authorisation request.
In order to start processing 3-D Secure transactions the following changes are required:
1.
Your Merchant Account needs to be confgured by Adyen to support 3-D Secure. If you would like to have 3-D
Secure enabled please submit a request to the Adyen Support Team ([email protected]).
2.
Your integration should support redirecting the shopper to the card issuer and submitting a second API call to
complete the payment.
The initial API call for both 3-D Secure and non-3-D Secure payments is almost identical, however, for 3-D Secure
payments you must supply the browserInfo object as a sub-element of the payment request, this is a container for the
acceptHeader and userAgent of the shopper's browser.
SOAP example:
<browserInfo xmlns="http://payment.services.adyen.com">
<acceptHeader xmlns="http://common.services.adyen.com">text/html,application/xhtml+xml,
application/xml;q=0.9,*/*;q=0.8</acceptHeader>
<userAgent xmlns="http://common.services.adyen.com">Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.9) Gecko/2008052912 Firefox/3.0</userAgent>
</browserInfo>
SOAP example:
paymentRequest.browserInfo.acceptHeader=text%2Fhtml%2Capplication%2Fxhtml%2Bxml%2Capplication
%2Fxml%3Bq%3D0.9%2C%2A%2F%2A%3Bq%3D0.8&paymentRequest.browserInfo.userAgent=Mozilla%2F5.0+
%28X11%3B+Linux+x86_64%29+AppleWebKit%2F537.31+%28KHTML%2C+like+Gecko%29+Chrome
%2F26.0.1410.63+Safari%2F537.31
Once your account is confgured for 3-D Secure, the Adyen system performs a directory inquiry to verify that the card is
enrolled in the 3-D Secure programme. If it is not enrolled, the response is the same as a normal API authorisation. If,
however, it is enrolled, the response contains these felds:
•
paRequest
The 3-D request data for the issuer.
•
md
The payment session.
•
issuerUrl
The URL to direct the shopper to.
14 / 68
API Manual
•
resultCode
The resultCode will be RedirectShopper.
The paRequest and md felds should be included in a HTML form which needs to be submitted using the HTTP POST
method to the issuerUrl. You must also include a termUrl parameter in this form which contains the URL on your site that
the shopper will be returned to by the issuer after authentication. We recommend that the form is “self-submitting” with a
fallback in case javascript is disabled. A sample form is shown below.
<body onload="document.getElementById('3dform').submit();">
<form method="POST" action="${issuerUrl}" id="3dform">
<input type="hidden" name="PaReq" value="${paRequest}" />
<input type="hidden" name="TermUrl" value="${termUrl}" />
<input type="hidden" name="MD" value="${md}" />
<noscript>
<br/>
<br/>
<div style="text-align: center">
<h1>Processing your 3-D Secure Transaction </h1>
<p>Please click continue to continue the processing of your 3-D Secure transaction.</p>
<input type="submit" class="button" value="continue"/>
</div>
</noscript>
</form>
</body>
After the shopper authenticates at the issuer they will be returned to your site by sending a HTTP POST request to the
TermUrl containing the MD parameter as explained previously and a new parameter called PaRes. These will be needed to
complete the payment.
To complete the payment the following parameters should be submitted to the authorise3d action:
•
merchantAccount
This should be the same as the Merchant Account used in the original authorise request.
•
browserInfo
It is safe to use the values from the original “authorise” request as they are unlikely to change during the course
of a payment.
•
md
The value of the MD parameter received from the issuer.
•
paResponse
The value of the PaRes parameter received from the issuer.
•
shopperIP (recommended)
The IP address of the shopper. We recommend that you provide this data, as it is used in a number of risk
checks, for example, the number of payment attempts and location based checks.
Please refer to Appendix I for an example of an authorise3d request.
15 / 68
API Manual
2.5. AVS
Address Verifcation Service (AVS) is a security feature that verifes the billing address of the card holder. It does so by
comparing the numeric portions of the card holder's registered billing address to those entered by the shopper. AVS is
only supported on a limited set of acquiring connections, card types, and only for a limited set of countries (United States,
Great Britain and Canada).
To use AVS you must supply the full address of the shopper using the billingAddress sub-element of the card element.
<billingAddress xmlns="http://payment.services.adyen.com">
<city xmlns="http://common.services.adyen.com">Burbank</city>
<street xmlns="http://common.services.adyen.com">South Buena Vista Street</street>
<houseNumberOrName xmlns="http://common.services.adyen.com">500</houseNumberOrName>
<postalCode xmlns="http://common.services.adyen.com">91521</postalCode>
<stateOrProvince xmlns="http://common.services.adyen.com">California</stateOrProvince>
<country xmlns="http://common.services.adyen.com">US</country>
</billingAddress>
Please note:
•
If you are submitting the billingAddress object all the sub-elements are mandatory, if some felds are not
provided you will receive an error response.
•
The country value must be provided as the 2-character ISO country code, for example, “GB” for the Great
Britain. An invalid country code may result in the payment request being rejected. The full list is available
here:
http://www.iso.org/iso/english_country_names_and_code_elements
•
The various card brands and networks have their own specifc AVS response codes; these are mapped to
Adyen's generic response codes that are sent to you by default. If you would like to receive the actual
response from the card or network, please contact the Adyen Support Team ([email protected]) to have the
Raw AVS Reason enabled for you. This will be included in the Notifcation that you receive.
2.6. Testing AVS and CVC/CVV Results
2.6.1.
Testing AVS Results
It is possible to test the 27 diferent AVS result codes. If the street feld of the billingAddress element has the value “Test
AVS result” you can specify the avsResult value in the houseNumberOrName feld. Note that all other billingAddress felds are
still required but their values do not impact the avsResult that is returned.
Please refer to Appendix K for the complete list of AVS result codes.
SOAP billingAddress element:
<billingAddress xmlns="http://payment.services.adyen.com">
<city xmlns="http://common.services.adyen.com">Burbank</city>
<street xmlns="http://common.services.adyen.com">South Buena Vista Street</street>
<houseNumberOrName xmlns="http://common.services.adyen.com">17</houseNumberOrName>
<postalCode xmlns="http://common.services.adyen.com">91521</postalCode>
<stateOrProvince xmlns="http://common.services.adyen.com">CA</stateOrProvince>
<country xmlns="http://common.services.adyen.com">US</country>
</billingAddress>
16 / 68
API Manual
REST billingAddress element:
paymentRequest.card.billingAddress.city=Burbank&paymentRequest.card.billingAddress.street=Sou
th+Buena+Vista+Street&paymentRequest.card.billingAddress.houseNumberOrName=17&paymentRequest.
card.billingAddress.postalCode=91521&paymentRequest.card.billingAddress.stateOrProvince=CA&pa
ymentRequest.card.billingAddress.country=US
Please note, when testing the AVS results it is important to ensure that you are using one of the AVS test card numbers
found here:
https://support.adyen.com/index.php?/Knowledgebase/Article/View/11/0
2.6.2.
Testing CVC/CVV Results
It is possible to test the 7 diferent CVC/CVV result codes. You will need to use one of the Adyen test cards that includes a
CVC and instead of inputting the CVC, enter the code you want to simulate.
Please refer to Appendix K for the complete list of CVC/CVV result codes.
SOAP card element:
<card xmlns="http://payment.services.adyen.com">
<cvc>004</cvc>
<expiryMonth>06</expiryMonth>
<expiryYear>2016</expiryYear>
<holderName>Adyen Test</holderName>
<number>4111111111111111</number>
</card>
REST card element:
&paymentRequest.card.cvc=004&paymentRequest.card.expiryMonth=06&paymentRequest.card.expiryYea
r=2016&paymentRequest.card.holderName=Test+Tester&paymentRequest.card.number=5555444433331111
Please note, when testing the CVC/CVV results it is important to ensure that you are using one of the test card numbers
that requires a CVC found here:
https://support.adyen.com/index.php?/Knowledgebase/Article/View/11/0
2.6.3.
Testing Error Codes
It is possible to test Refused transactions and their specifc Refusal reasons by placing the following text in the Card
Holder Name:
[Response code] : [The refusal reason raw String that is tested]
For example:
DECLINED : 05 : ISSUER_UNAVAILABLE
Other response codes that are available for testing are:
•
•
•
•
•
•
•
•
•
•
REFERRAL
ERROR
BLOCK_CARD
CARD_EXPIRED
DECLINED
INVALID_AMOUNT
INVALID_CARD
NOT_SUPPORTED
NOT_3D_AUTHENTICATED
NOT_ENOUGH_BALANCE
17 / 68
API Manual
•
APPROVED
Please note:
•
There is a limit in characters of the Card Holder Name. The result may be:
DECLINED : 05 : ISSUER_UNAVAIL
•
You may have to lower the risk score for non-alphabetic characters in the card holder name as the ':' character
will trigger this check and may cause the payment to be declined with reason code "FRAUD".
•
An incorrect CVC or invalid expiry date will override the response code and always lead to a generic
"DECLINE".
2.7. Card Verifcation/Dynamic Zero Value Auth
In order to verify a card's validity, you may submit an authorisation request with an amount value of 0, the currency
should match the eventual transaction currency. This will result in the Adyen system submitting a card verifcation call,
also referred to as a “Zero Value Auth”, to the Acquirer, the resultCode will return either Authorised or Refused.
Not all Acquirers support card verifcation, in the situation where your transactions are routed to an Acquirer that does
not support this feature, the Adyen system will automatically submit a EUR 1 authorisation followed by an automatic
cancel of the authorisation. For other currencies, the EUR 1 approximate equivalent value is used, for example, 1000
Korean Won (KRW) as 1 KRW is too low an amount to be authorised.
18 / 68
API Manual
2.8. Installments
Some Acquirers, most notably in South America, support installments whereby the shopper is not charged the full
payment amount in one charge, but is split at specifed intervals over a fxed period. Please contact the Adyen Support
Team ([email protected]) for more details about the Acquirers that support this functionality.
To support installments an additional object must be submitted in the authorise payment request:
•
installments
A container for the installment data.
◦
Value = <the number of installments>
The number of installments must be greater than zero.
There typically is a limit on the maximum number of installments, for example 24, but this is an Acquirer
specifc limit.
Please refer to Appendix J to review a payment request with the number of installments is set to 4.
Please note, Adyen provides a WSDL that contains the installments feld; you can fnd this in Appendix A.
2.9. Additional Payment Response Data
If required, extra response felds can be added to the SOAP response in the additionalData object; these are not enabled
by default. Please contact the Adyen Support Team ([email protected]) if you wish to enable this for your Merchant
Account.
•
authCode
The authorisation code if the payment was successful. Blank otherwise.
•
cvcResult
The CVC result of the payment; please refer to Appendix K for the list of possible values that my be returned.
•
avsResult
The AVS result of the payment; please refer to Appendix K for the list of possible values that my be returned.
•
referred
When the payment is referred the value of this feld will be true; otherwise the feld will not be available. Please
note, this is not typically returned for eCommerce transactions.
Where available, you may choose to receive the raw results that we receive from the Acquirer. This is an extra setting that
must be enabled for your Merchant Account by the Adyen Support Team ([email protected]). The setting will add the
following felds to the additionalData object of the SOAP response.
•
cvcResultRaw
The raw CVC result received from the Acquirer where available.
•
avsResultRaw
The raw AVS result received from the Acquirer where if available.
•
refusalReasonRaw
The raw refusal reason received from the Acquirer where available.
19 / 68
API Manual
3. Idempotency In The Adyen API
When interfacing with an API, dealing with failures and retries can be challenging. Adyen's API attempts to limit the impact
of such a problem:
•
Asynchronous server-to-server notifcations inform you of the result of a request to the API. This is particularly
useful in the eventuality that an authorisation response is missed, this may occur due to a timeout; please refer
to section 8 for information regarding notifcations.
•
Capture and refunds requests are validated against balances in the accounting system.
◦
It is not possible to capture more than the initial authorisation amount.
◦
By default the system does not allow you to refund more than the original captured amount, but this may
be enabled.
While this is usually sufcient to deal with most exceptions, you may also choose to use the Adyen API in idempotent
mode. Idempotency is an API feature where repeatedly submitting the same message to the API always produces the
same response message but the action requested by the message is only executed once. This allows your system to safely
retry an API call in the case of failure without worrying about the payment being duplicated.
3.1. Idempotency Implementation
To trigger idempotency, you simply need to set the relevant HTTP headers. Messages will be uniquely identifed using a
message key which is a combination of the Merchant Account and Merchant Reference. As such, you will need to ensure
that you are always using a unique Merchant Reference for each payment request. You must also provide a unique
Merchant Reference for each modifcation message (capture/refund/cancel).
A set of standard HTTP request/response headers will trigger the idempotent behaviour and report back the status.
Please refer to http://www.w3.org/Protocols/rfc2616/rfc2616.html for more details.
Idempotent behaviour is triggered using the Pragma directive.
Pragma= "Pragma" ":" 1#pragma-directive
pragma-directive
= "process-idempotent" | "process-idempotent-initial"
When to use "process-idempotent" or "process-idempotent-initial"?
•
"process-idempotent" can be used if your system requires a "Strict Consistency" model to ensure idempotency,
meaning that a “system unavailable” error response may be generated if the idempotency service is not fully
available at the time of processing the request.
•
If your system is issuing an initial payment request, not a retry, the directive "process-idempotent-initial" can be
used and the request will be processed as above. The diference is that, if the idempotency service is unavailable,
the request will still be processed. In this case the response will be added later to the idempotency store in an
"Eventual Consistency" model. To avoid double-processing, this mode should NOT be used when retrying a
request or if your system is unsure if the request is an initial request.
When idempotent behaviour is requested a message generation date header is mandatory.
Date = "Date" ":" HTTP-date
Retries of the original request are, by default, required to pass the same value in the date header. A mismatch between
the value of the date header and the message key will result in a validation error response from the API: “Message request
date does not match original request date”. Values are compared by parsing the value to a GMT timestamp value with
"second" precision.
20 / 68
API Manual
It is possible to bypass this check, by adding “idempotent-no-check-date” to the Pragma directive. Please note, the values in
the Pragma directive are comma-separated.
When processing a request idempotently, the response will contain a Last-Modifed header containing the date the
original response was generated.
Last-Modified = "Last-Modified" ":" HTTP-date
Please note, HTTP-date is required as part of the HTTP standard and should conform to the RFC 1123 format; this difers
from the ISO date format (ISO 8601) that Adyen uses in the APIs.
3.2. Retrying transactions and Idempotency
There may be some scenarios in which you may want to retry a transaction.
3.2.1.
Refused Transactions
If, for example, a transaction is Refused and you want to ofer the customer the ability to enter new payment details, you
would send a new merchantReference, which may be as simple as applying a sufx, such as 12345-2. To avoid any issues
with (mis)identifying duplicates, the Adyen platform does not perform a full message analysis, it only checks the key, and
optionally the date header. We consider a resultCode of Authorised/Refused to be a valid fnal response. With
idempotency re-sending the same key will reproduce this fnal message.
3.2.2.
Transient Errors
If a request fails due to a timeout or a communication error, and we have the expectation that a retry is likely to succeed,
we will mark the response as a transient error. A transient error response will have the Pragma directive set with value
“transient-error”. Transactions marked as transient errors are not considered to be in a fnal state and, if resubmitted, will
be reprocessed. When reprocessing, we will return a new response, which may again be a transient error.
Pragma= "Pragma" ":" 1#pragma-directive
pragma-directive
= "transient-error"
21 / 68
API Manual
4. One-Click Payments
One-Click Payments can be used to allow repeat/known shoppers to pay without re-entering their payment details. The
shopper can be given the opportunity to store their payment details when they frst pay and is able to use these details
for subsequent requests. For One-Click Payments the shopper will have to enter their credit card's CVC. Currently OneClick payments only work for Card payments.
Please refer to the Adyen Recurring Manual for more details regarding managing and submitting Recurring payments.
4.1. The Initial Payment
The initial payment , or subsequent payments with diferent details, are processed as normal payment requests as
described in section 2. The only diference is the addition of the Recurring object to the payment request, and that the
shopperReference and shopperEmail felds are required.
The Recurring object contains the following felds:
•
contract
This should be set to ONECLICK.
•
recurringDetailName (optional)
A short description entered by the shopper to identify their payment details. For example, “My wife's
MasterCard”.
If the payment is successful the details are stored.
4.2. Submitting A One-Click Payment
When submitting a payment using a payment detail returned from listRecurringDetails, you generate a normal payment
request which follows the same rules as the initial payment, meaning that the shopperReference and shopperEmail are
required and that a Recurring object should be present and contain the value ONECLICK for the contract feld. However, the
recurringDetailName should not be supplied.
One additional feld is added to the payment request:
•
selectedRecurringDetailReference
This is the recurringDetailReference you want to use for this payment, the customer will need to provide the CVC
for the selected card and so the value LATEST cannot be used.
In the case of a card payment you should supply a card object in the payment request with only the cvc feld and value
populated.
22 / 68
API Manual
5. Card Deposit (CFT)
Card Deposit, also referred to as Card Funds Transfer (CFT), allows you to transfer funds directly onto a credit card. There
are two methods to do this:
1.
Refund an existing transaction for an amount exceeding the original transaction amount. This does not require
you to know the card details, only a reference to the existing transaction.
2.
Directly deposit funds on a card without an existing transaction. This requires you to submit the card details and
is much like the process for submitting a direct payment.
Both methods are disabled by default. Please contact the Adyen Support Team ([email protected]) if you would like to
submit card deposits.
5.1. Card Deposit Using An Existing Transaction
To deposit an amount using an existing transaction send a FundTransferRequest using the fundTransfer action containing
the following felds:
•
merchantAccount
The merchant account the original payment was processed with.
•
modifcationAmount
The amount to deposit. This consists of a currencyCode and a paymentAmount4. The currencyCode must match the
currency used in the original payment.
•
originalReference
This is the pspReference that was assigned to the original payment. It is received with the payment status or with
the authorisation notifcation.
•
reference
Your reference for this payment. This reference will be used in all communication to you regarding the status of
the payment. We recommend using a unique value per payment but this is not a requirement.
•
shopperEmail (optional)
The shopper's email address.
If the message is syntactically valid and the merchantAccount is correct, you will receive a response with the following
felds:
•
pspReference
A new unique reference Adyen has assigned to identify this deposit. This is guaranteed to be globally unique and
should be used when communicating with us about this payment.
•
response
If successful, this value returned will be [fundtransfer-received], if unsuccessful an informational message will be
returned.
Please note, that [fundtransfer-received] does not mean that the card deposit was successful, it means that Adyen has
successfully received the message. The actual transfer is executed ofine and the fnal result communicated using a
notifcation, please see Section 5.3 for details.
5.2. Directly Depositing Funds On A Card
The process to directly deposit funds on to a card, without reference to an existing transaction, is similar to submitting a
payment to the API, please refer to section 2. The request is exactly the same as for a payment request but the request is
submitted to the refundWithData method rather than the authorise method.
4
Please refer to “Explanation of the Session Fields” section in the Adyen Merchant Integration Manual.
23 / 68
API Manual
5.3. CFT Notifcations
Notifcations for card deposits, using both methods, are the same as for payments but the eventCode is
REFUND_WITH_DATA, please refer to the Notifcations section in the Adyen Merchant Integration Manual for more
information. As with regular payments you should check the success parameter to determine if the deposit succeeded.
24 / 68
API Manual
6. Direct Debit Payments
The European Payments Council (EPC) has mandated that as of 1st February 2014, all merchants that are currently
processing, or planning to process, ELV or Incasso payments, must have implemented SEPA Direct Debits (DD).
6.1. US ACH Payments
ACH (Automated Clearing House) payments are a form of Electronic Direct Debit used in the United States.
The payment request is similar to a credit card request but rather than supplying a card you supply a bankAccount
container with the following felds:
•
bankAccountNumber
The US shopper's bank account number, this is a numeric feld.
•
bankLocationId
The shopper's bank transit routing number, a nine digit number – leading zeroes should not be stripped out.
•
bankAccountType
The value 'C' for a checking account or 'S' for a savings account.
•
ownerName
The bank account holder name.
•
countryCode
The value 'US'.
For ACH payments shopperReference and shopperIP are required felds.
6.1.1.
ACH Transaction Types
The ACH transaction types WEB and TEL are supported:
•
WEB - Internet-Initiated Transactions
WEB is used when a merchant is authorised by the consumer, via the Internet, to create an ACHP debit. The WEB
code applies to both single-entry and recurring payments. WEB transactions must be drawn on a consumer
account and are payable in U.S. currency.
•
TEL – Telephone-Initiated Transactions
TEL may only be used when a consumer initiates contact with the merchant or there is a previously existing
relationship between the merchant and the consumer, this is defned as the consumer having made a purchase
from the merchant within the past two years.
A transaction's Shopper Interaction will determine how the transaction will be processed; this is confgured at the Merchant
Account level or using an override per transaction. eCommerce transactions will be processed as WEB, ContAuth will
cause the transaction to be processed as WEB recurring and MOTO transactions will be processed as TEL.
Please refer to Appendix L for a sample SOAP & REST ACH Payment request.
6.1.2.
ACH Response
The response for ACH payments is similar to card payments, however an authorisation code is not generated or returned.
6.1.3.
ACH Chargebacks
ACH payments may be reversed by the account holder after settlement, which will result in a payment status of
Chargeback. The process is comparable with a Credit Card chargeback but without the ability to defend against the
dispute.
25 / 68
API Manual
6.2. SEPA Direct Debits
The Single Euro Payments Area (SEPA) is an EU payment-integration initiative for the simplifcation of bank transfers
denominated in EUR. The European Payments Council (EPC) has mandated that as of 1st August 2014, all merchants
that are currently processing ELV or Incasso (Dutch Direct Debit) payments, must have implemented SEPA Direct Debits
(SDD). Please refer to the SEPA Migration Manual for more details on migrating ELV or Incasso payments to SDD:
https://support.adyen.com/index.php?/Knowledgebase/Article/View/2112/101/sepa-migration-manual
Please note, there is still some ongoing development and as a result this document is subject to change.
6.2.1.
One-of SDD Payment Requests
The payment request will include the bankAccount container that contains the following elements:
•
iban
The IBAN.
•
bic
The unique identifcation code for both fnancial and non-fnancial institutions.
•
ownerName (optional)
The name of the account holder.
In addition to the bankaccount container, you must also include:
•
selectedBrand
The value should be “sepadirectdebit”.
Please refer to Appendix M for an example of a sepadirectdebit one-of API payment request.
6.2.2.
Recurring SDD Payment Requests
The only change to the payment request is that you must include the selectedBrand element.
Please refer to Appendix N for an example of a sepadirectdebit recurring API payment request.
26 / 68
API Manual
6.2.3.
SDD Notifcations
Pending Notifcation
The Pending notifcation is not enabled by default. Once enabled, the notifcation is sent out at the moment the payment
is created. Please contact Adyen support ([email protected]) if you want to receive this additional notifcation.
<com.adyen.services.notification.NotificationRequestItem>
<pspReference>9913856361050084</pspReference>
<merchantReference>Test Payment Reference</merchantReference>
<merchantAccountCode>SupportAdyenTest</merchantAccountCode>
<eventDate>2013-11-28 11:55:05.934 CET</eventDate>
<eventCode>PENDING</eventCode>
<amount>
<value>1500</value>
<currency>EUR</currency>
</amount>
<success>true</success>
<paymentMethod>sepadirectdebit</paymentMethod>
<additionalData>
<entry>
<string>sepadirectdebit.dateOfSignature</string>
<string>2013-11-28</string>
</entry>
<entry>
<string>sepadirectdebit.sequenceType</string>
<string>First</string>
</entry>
<entry>
<string>sepadirectdebit.mandateID</string>
<string>9913856361050084</string>
</entry>
</additionalData>
Authorisation Notifcation
<eventCode>AUTHORISATION</eventCode>
<amount>
<value>1500</value>
</amount>
<reason/>
27 / 68
API Manual
Extended Authorisation Notifcation
The extended notifcation is not enabled by default. Please contact Adyen support ([email protected]) if you want to
receive the extended notifcation.
<amount>
<value>1500</value>
</amount>
<reason/>
<additionalData>
<entry>
<string>sepadirectdebit.dateOfSignature</string>
<string>2013-11-28</string>
</entry>
<entry>
<string>sepadirectdebit.sequenceType</string>
<string>First</string>
</entry>
<entry>
<string>sepadirectdebit.mandateID</string>
<string>9913856361050084</string>
</entry>
</additionalData>
6.2.4.
SDD Settlement Timeline
Prior to initiating the DD, you will need to inform the customer that the payment is due.
Core
Event:
SDD First
SDD Recurring
Pre-notifcation
(T-14) T-5
(T-14) T-2
Submit SDD instructions (Moment of payment
request)
T-5
T-2
Latest moment to revoke (cancel) SDD
T-1
T-1
SDD instruction processed by bank
T
T
Reconciliation by Adyen PSP
T+1
T+1
28 / 68
API Manual
Core 1
Core 1 is automatically used in Germany, Spain and Austria.
Event:
SDD
SDD Recurring
Pre-notifcation
(T-14) T-1
(T-14) T-2
Submit SDD instructions
T-1
T-2
Latest moment to revoke (cancel) SDD
N/A
T-1
SDD instruction processed by bank
T
T
Reconciliation by Adyen PSP
T+1
T+1
6.2.5.
SDD Chargebacks
The chargeback process is standardised for all SEPA DD variants. The SEPA DD schemes ensure more protection and
refund rights for consumers:
•
The shopper can have the authorised SEPA DD payment returned within 8 weeks.
•
The shopper has 13 months to report incorrect unauthorised SEPA DD with their bank and request a reversal, as
the debit was not authorised or the mandate was expired or had been cancelled.
Both scenarios result in a payment status of Chargeback. The process is comparable with a Credit Card chargeback but
without the possibility to defend against the dispute.
6.3. ELV Payments – deprecated 1 st August 2014
ELV (Elektronisches Lastschriftverfahren) payments are a form of Electronic Direct Debit which are very popular in
Germany.
The payment request is the same as for a credit card request but rather than supplying a card container you supply an elv
container with the following felds:
•
bankLocation
The city in which the bank (branch) is located.
•
bankName
The name of the bank.
•
bankLocationId
The location ID (Bankleitzahl) of the bank.
•
accountHolderName
The name of the account holder.
•
bankAccountNumber
The account number (Kontonummer).
A sample ELV element is shown below:
<elv xmlns="http://payment.services.adyen.com">
<accountHolderName>S. Hopper</accountHolderName>
<bankAccountNumber>1611613</bankAccountNumber>
<bankLocation>Hamburg</bankLocation>
<bankLocationId>20010020</bankLocationId>
<bankName>Postbank Hamburg</bankName>
</elv>
29 / 68
API Manual
6.4. Dutch Incasso Payments – deprecated 1 st August 2014
Dutch Incasso payments are a form of Electronic Direct Debit used in the Netherlands.
The request is similar to a credit card request but rather than supplying a card object you supply a bankAccount object
with the following felds:
•
bankAccountNumber
A numeric feld for the Dutch bank account number which is either a 9-digit account number that complies with
the Dutch elfproef5 or a Postbank number (see below).
•
ownerName
The bank account holder name.
•
bankName
The feld is set to 'ING' for ING (or former Postbank) accounts, for non-ING accounts the feld is optional but we
recommend that it is provided.
•
countryCode
The value 'NL'.
Please note, Direct Debit payments were formerly submitted to the directdebit action rather than the authorise action.
The directdebit action is deprecated as of January 1 2011, but will be maintained until further notice for backward
compatibility.
Please refer to Appendix O for a sample SOAP Incasso Payment request.
6.4.1.
Incasso Response
For every transaction submitted you will receive an authoriseResponse, for all transactions that are successfully submitted,
Adyen will return a value of Received in the resultCode feld; this is not an indication that the transaction was successful,
just that Adyen has received the request.
For bank account numbers that are invalid, blacklisted or otherwise not acceptable, there are two possible responses:
•
In the case of an invalid bank account number or an invalid message, a SOAP exception will be returned.
•
A resultCode of Refused in the situation where a fraud check was triggered, the response will contain the refusal
reason FRAUD.
If the account number is accepted and the resultCode is Received the transaction will be submitted, by Adyen, to the
banking network in the next Incasso batch, the cutof time for inclusion in the batch is 12pm CET. It is not possible to
schedule Incasso payments for later processing.
When the batch is submitted to the banking network every transaction can end up in one of two statuses:
•
Authorised immediately followed by SentForSettle, followed by Settled: The transaction is accepted, the money has
been received by Adyen, and will be settled to the merchant.
•
Refused: The transaction has been refused by the banking network.
6.4.2.
Incasso Chargebacks
Incasso payments can be reversed by the account holder up to 30 days after settlement, which will result in a payment
status of Chargeback. The process is comparable with a Credit Card chargeback but without the ability to defend against
the dispute.
5
Please refer to the following site for more details: http://nl.wikipedia.org/wiki/Elfproef
30 / 68
API Manual
6.4.3.
Incasso Statement Text
The consumer's statement will contain Adyen's bank account number and the name ADYEN. The actual account holder is
the Adyen Client Management Foundation. Two further lines of information will be printed:
•
PspReference: 16 characters (Payment Reference).
•
Shopper Statement: 32 characters (Fixed or supplied as shopperStatement).
Here is an example of an Incasso statement line that a consumer would see:
1323.94.782
1415362362372721
UW ORDER 122345677889
ADYEN
Please ensure that your customers are informed that they can expect to see Adyen displayed on their statements.
6.4.4.
Incasso Legal Requirements
For Incasso payments you need a signed mandate from the bank account holder, this is true for both one-of and
recurring Incasso payments.
31 / 68
API Manual
7. Boleto Bancário
Boleto Bancário, often simply referred to as Boleto, is an ofine payment method used in Brazil . The consumer will take
the Boleto form to an ATM, bank, an approved facility, or access their online banking system to complete the payment.
Once the Boleto is paid, the bank will send Adyen a fle confrming that the payment was made, this usually takes one day,
but it may occur up to 6 days after the payment. If a Boleto is not paid, the transaction will expire once the expirationDate
is reached.
The payment request will contain the data that is displayed on the Boleto. The billingAddress, deliveryDate and
shopperStatement felds are optional but may be used to customise the Boleto form:
•
deliveryDate (optional)
This is the date by which the consumer must submit their payment; there aren't any time restrictions on the date
inserted, however, if you do not populate this feld the Adyen system will insert a date 5 days from the creation
date.
•
shopperStatement (optional)
In this context the feld can be used to provide the consumer with customised instructions for submitting their
payment; if you do not provide this feld, the default text will be displayed:
Não receber após o vencimento.
Não aceitar o pagamento com cheque.
This translates to:
Do not accept payment after the due date.
Do not accept payment by cheque.
If you would like to add a line break in the shopper statement, you must use the following code:
SOAP:
"
”
REST:
"%0A"
•
socialSecurityNumber (mandatory)
The consumer will need to provide their Cadastro de Pessoas Físicas (CPF) number.
•
frstName and lastName (mandatory)
Shopper's full name.
Please refer to Appendix P and Appendix Q for examples of SOAP and REST Boleto requests and responses.
When submitting a Boleto payment, the Adyen system will return a URL to you in the feld boletobancario.url. You may use
this to download the PDF of the Boleto or redirect the consumer to it. This will render the Boleto form that the shopper
must use to complete their payment at an ATM, bank or approved facility. The PDF may be accessed until the
expirationDate, this is the deliveryDate + 15 days, at this time the transaction will expire in the Adyen system.
Please refer to Appendix R for sample Boleto forms.
7.1. Boleto Notifcations
Adyen will send a PENDING notifcation once the Boleto transaction is created in the Adyen system. We will return the
additionalData.acquirerReference, in the notifcation, you may want to store this data as it is the Boleto's "Nosso Numero"
or ID at the bank.
Adyen will send an AUTHORISATION notifcation once we have received confrmation from the bank that the Boleto has
been paid.
32 / 68
API Manual
33 / 68
API Manual
7.2. Important Information Regarding Storage Of The
Boleto PDF
The Boleto contains sensitive information, namely the consumer's address and CPF; the Adyen URL is not available via a
direct link but if you do decide to download the PDF and make it available on your systems, it is important to ensure that
it is only available from a secure location, this is the recommended approach. If, however, you do intend to store the fles
in a publicly available area, we suggest ensuring that the content is not indexed, you may use the following command in
the HTTP header where the fle is being served: X-Robots-Tag:noindex. This will prevent the PDF fle from being accessed by
search engines and will not appear in search results pages.
34 / 68
API Manual
8. Notifcations
Whenever a payment is made, a modifcation is processed or when a report is available for download, we will notify you
of the event and whether or not it was performed successfully. Notifcations should be used to keep your backofce
systems up to date with the status of each payment and modifcation.
Notifcations are sent using either a SOAP call or using HTTP POST parameters to a server, that you host, that will receive
and accept the notifcations. We provide code examples in common programming languages for this, please refer to the
link in the Introduction. Your system should be able to handle requests/responses which contain additional felds and
duplicate notifcations for the same transaction.
Due to the nature of the Adyen platform, an AUTHORISATION notifcation may be sent twice. The front end systems (HPP)
will attempt to send the notifcation as soon as the payment is made. However our front-end systems do not register if
this notifcation is received successfully by your servers. This is done on a central application and hardware instance
which updates the accounting journal entries for each transaction. This system not only sends at least one notifcation, it
also records whether or not it was successfully received, this is determined by your server responding to the notifcation
with a message indicating that the notifcation has been [accepted]. Please refer to section 8.2 for more details regarding
accepting notifcations.
Notifcations will be resent if their delivery has failed or if the delivery is uncertain. This at-least-once delivery rule implies
that you may receive the same notifcation twice. A duplicate notifcation is one where the eventCode and pspReference
felds are the same (see below). If a duplicate is received with the success feld set to true it overrules the previous
notifcation. In all other cases you do not need to act on duplicate notifcations.
Notifcation settings are confgured in the Adyen CA. You can set the method (HTTP POST/SOAP), URL to submit to, and
user name/password for HTTP Basic authentication. Default HTTP (TCP port 80) and HTTPS (TCP port 443) are allowed, as
well as extra TCP ports 8080, 8888 (for HTTP) and 8443, 8843 (for HTTPS) if needed.
8.1. Notifcation Message Fields
A notifcation contains the following felds for each transaction that it references:
•
live
boolean (true/false) indicating if the notifcation originated from the LIVE or TEST payment systems.
•
eventCode
The event type of the notifcation. Values include:
Normal Payment Events
◦ AUTHORISATION.
Modifcation Payment Events
◦ CANCELLATION.
◦
REFUND.
◦
CANCEL_OR_REFUND.
◦
CAPTURE.
◦
REFUNDED_REVERSED.
Please note that the success feld in a REFUNDED_REVERSED notifcation will always be set to false.
◦
CAPTURE_FAILED.
◦
REFUND_FAILED.
Dispute Events
◦ REQUEST_FOR_INFORMATION.
◦
35 / 68
API Manual
NOTIFICATION_OF_CHARGEBACK.
◦
ADVICE_OF_DEBIT.
◦
CHARGEBACK.
◦
CHARGEBACK_REVERSED.
For more information about Disputes please refer to the Merchant Manual.
Please note that the success feld in a CHARGEBACK_REVERSED notifcation will always be set to true.
Other Events
◦ REPORT_AVAILABLE.
For more information please refer to the Adyen Reporting Manual.
For specialised applications, such as recurring payments, other values are possible. Please note, Adyen may add new
codes at any time and, as such, your listening service should not be coded to expect a fxed set of values.
•
pspReference
The unique reference that Adyen assigned to the payment or modifcation.
•
originalReference
If this is a notifcation for a modifcation request this will be the pspReference that was originally assigned to the
authorisation, for a payment it will be blank.
•
merchantReference
This is the reference you assigned to the original payment.
•
merchantAccountCode
The merchant Account the payment or modifcation was processed with.
•
eventDate
The time the event was generated.
•
success
Whether or not the event succeeded (boolean true/false).
•
paymentMethod
The payment method used, this is only populated for an AUTHORISATION. e.g. visa, mc, ideal, elv, wallie, etc.
•
operations
This feld displays the modifcation operations supported by this payment as a list of strings, this is only
populated for AUTHORISATION notifcations. The operations will inform you whether you need to capture the
payment (if you don't have auto-capture set up), whether you can cancel the payment (before capture) or if you
can refund the payment (after it has been captured). Values include:
◦
CAPTURE.
◦
REFUND.
◦
CANCEL.
For HTTP POST notifcations, the operations are sent as a single comma-separated string.
•
reason
Text feld with information depending on whether the result is successful or not. For AUTHORISATION events with
the success feld set to true and a payment method of visa, mc or amex this feld contains the authorisation
code, the last 4 digits of the card, and the expiry date in the following format:
6 digit Authorisation Code:Last 4 digits:Expiry Date. For example, 874574:1935:11/2012.
When the success feld is set to false it gives a reason as to why it was refused. For REPORT_AVAILABLE it contains
the URL where the report can be downloaded from.
•
amount
The amount, if applicable, associated with the payment or modifcation. This consists of a currencyCode and a
value which is the amount in minor units. For HTTP POST notifcations, you will receive the currency and value as
parameters.
36 / 68
API Manual
For SOAP notifcations a notifcation message is a container for an array of notifcation items, meaning that you may
receive multiple notifcations within a single message. Please refer to Appendix S for a sample SOAP notifcation and
response. Please refer to Appendix T for a sample REST notifcation and response.
Please note that the eventCode AUTHORISATION does not necessarily mean that the authorisation is successful. The
authorisation is successful if the success feld has the value true. In case of an error or a refusal, it will be false and the
reason feld should be consulted for the cause of the authorisation failure.
8.2. Accepting Notifcations
The Adyen notifcation system requires a response within 30 seconds of receipt of the notifcation, the server is expecting
a response of [accepted], including the brackets. When our systems receive this response all notifcations contained in the
message are marked as successfully sent. It is important that Adyen receives the [accepted] message within 30 seconds
and that this process is not interrupted by any errors in processing the notifcation. As such, we recommend that the
acceptance of notifcations is handled separately from the processing of the notifcations, and that an [accepted]
response is generated when a notifcation has been stored. Please refer to Appendix S for a SOAP notifcation and
response. Please refer to Appendix T for a sample REST notifcation and response.
The URL to send the SOAP notifcation messages to and the authentication are confgurable in the Adyen CA. There is also
a testing facility that you can use to verify that your server is able to correctly receive the notifcations coming from the
Adyen systems.
Please note that if you receive a notifcation which you cannot handle, either because the original transaction is not
recognised or because the eventCode is unknown, you should accept the message and store, or at least log, the item. Not
accepting the message may cause our system to halt sending notifcations.
37 / 68
API Manual
9. API Fault Codes
In the following situations the Adyen platform does not accept or store a submitted request:
•
If the request does not pass validation.
•
If the request violates a security constraint.
•
If the request confguration constraint.
Instead you will receive a SOAP Fault which will contain a description of the problem. Generally this will be handled as an
Exception in your SOAP toolkit. Payment requests which are rejected with a SOAP Fault will not be charged.
If the modifcation was rejected a faultstring is returned that adheres to the following syntax:
<faultstring> ::= <type> ' ' <message>
<type> ::= 'validation' | 'security' | 'confguration' | 'internal'
<message> ::= unicode
SOAP Example:
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance">
<soap:Body>
<soap:Fault>
<faultcode>soap:Server</faultcode>
<faultstring>validation 101 Invalid card number</faultstring>
</soap:Fault>
</soap:Body>
</soap:Envelope>
REST Example:
HTTP/1.1 500 Internal Server Error
security 901 Invalid Merchant Account
The way to check the description this is to read the faultstring. If the payment was rejected by our platform the fault string
will start with one of validation, security, or confguration followed by a code and it's descriptive message.
Please refer to Appendix U for a list of the error codes and messages.
38 / 68
API Manual
Appendix A: TEST and LIVE URLs
TEST URLs
SOAP
REST
Payment Service
https://pal-test.adyen.com/pal/servlet/soap/Payment
Payment Service WSDL
https://pal-test.adyen.com/pal/Payment.wsdl
Payment Service WSDL with
Installments
https://pal-test.adyen.com/pal/servlet/Payment/v4?wsdl
HTTP Adapter (Browser)
https://pal-test.adyen.com/pal/adapter/httppost?Payment
Authorisation
https://pal-test.adyen.com/pal/adapter/httppost?Payment.authorise
Test Capture
https://pal-test.adyen.com/pal/adapter/httppost?Payment.capture
Test Refund
https://pal-test.adyen.com/pal/adapter/httppost?Payment.refund
Test Cancel
https://pal-test.adyen.com/pal/adapter/httppost?Payment.cancel
LIVE URLs
SOAP
REST
39 / 68
API Manual
Payment Service
https://pal-live.adyen.com/pal/servlet/soap/Payment
Payment Service WSDL
https://pal-live.adyen.com/pal/Payment.wsdl
Payment Service WSDL with
Installments
https://pal-live.adyen.com/pal/servlet/Payment/v4?wsdl
HTTP Adapter (Browser)
https://pal-live.adyen.com/pal/adapter/httppost?Payment
Authorisation
https://pal-live.adyen.com/pal/adapter/httppost?Payment.authorise
Test Capture
https://pal-live.adyen.com/pal/adapter/httppost?Payment.capture
Test Refund
https://pal-live.adyen.com/pal/adapter/httppost?Payment.refund
Test Cancel
https://pal-live.adyen.com/pal/adapter/httppost?Payment.cancel
Appendix B: SOAP API Payment Request and Response
SOAP Payment Request
<soap:Body>
<ns1:authorise xmlns:ns1="http://payment.services.adyen.com">
<ns1:paymentRequest>
</amount>
<cvc>737</cvc>
<number>4111111111111111</number>
</card>
<merchantAccount
xmlns="http://payment.services.adyen.com">SupportAdyenTest</merchantAccount>
<reference xmlns="http://payment.services.adyen.com">Your Reference Here</reference>
<shopperEmail xmlns="http://payment.services.adyen.com">[email protected]</shopperEmail>
<shopperIP xmlns="http://payment.services.adyen.com">61.294.12.12</shopperIP>
<shopperReference xmlns="http://payment.services.adyen.com">Simon
Hopper</shopperReference>
</ns1:paymentRequest>
</ns1:authorise>
</soap:Body>
</soap:Envelope>
SOAP Payment Response
<soap:Body>
<ns1:authoriseResponse xmlns:ns1="http://payment.services.adyen.com">
<ns1:paymentResult>
<authCode xmlns="http://payment.services.adyen.com">64158</authCode>
<dccAmount xmlns="http://payment.services.adyen.com" xsi:nil="true"/>
<dccSignature xmlns="http://payment.services.adyen.com" xsi:nil="true"/>
<fraudResult xmlns="http://payment.services.adyen.com" xsi:nil="true"/>
<issuerUrl xmlns="http://payment.services.adyen.com" xsi:nil="true"/>
<md xmlns="http://payment.services.adyen.com" xsi:nil="true"/>
<paRequest xmlns="http://payment.services.adyen.com" xsi:nil="true"/>
<pspReference xmlns="http://payment.services.adyen.com">8313547924770610</pspReference>
<refusalReason xmlns="http://payment.services.adyen.com" xsi:nil="true"/>
<resultCode xmlns="http://payment.services.adyen.com">Authorised</resultCode>
</ns1:paymentResult>
</ns1:authoriseResponse>
</soap:Body>
</soap:Envelope>
40 / 68
API Manual
Appendix C: REST API Payment Request and Response
REST Payment Request
action=Payment.authorise
&paymentRequest.merchantAccount=SupportAdyenTest&paymentRequest.amount.value=1234&action=Payment.a
uthorise&paymentRequest.card.expiryYear=2016&paymentRequest.amount.currency=EUR&paymentRequest.car
d.cvc=737&paymentRequest.card.number=5555444433331111&paymentRequest.card.holderName=Test
%2BTester&paymentRequest.card.expiryMonth=06&paymentRequest.reference=testReference1234
REST Payment Response
paymentResult.pspReference=8513939253477759&paymentResult.authCode=9693&paymentResult.resultCode=A
uthorised
41 / 68
API Manual
Appendix D: CSE Source Libraries Used
RSA and ECC in JavaScript
The jsbn library is a fast, portable implementation of large number math in pure JavaScript, enabling public-key crypto
and other applications on desktop and mobile browsers.
http://www-cs-students.stanford.edu/~tjw/jsbn/
Stanford Javascript Crypto Library (AES)
The Stanford Javascript Crypto Library is a project by the Stanford Computer Security Lab to build a secure, powerful, fast,
small, easy-to-use, cross-browser library for cryptography in Javascript.
http://crypto.stanford.edu/sjcl/ .
42 / 68
API Manual
Appendix E: CSE Sample Encrypted Form
<!DOCTYPE html>
<html lang="en">
<head>
<title>Example Payment Form</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<form method="POST" action="#handler" id="adyen-encrypted-form">
<fieldset>
<legend>Card Details</legend>
<div class="field">
<label for="adyen-encrypted-form-number">Card Number
<input type="text" id="adyen-encrypted-form-number" value="5555444433331111" size="20"
autocomplete="off" data-encrypted-name="number" />
</label>
</div>
<div class="field">
<label for="adyen-encrypted-form-holder-name">Card Holder Name
<input type="text" id="adyen-encrypted-form-holder-name" value="John Doe" size="20"
autocomplete="off" data-encrypted-name="holderName" />
</label>
</div>
<div class="field">
<label for="adyen-encrypted-form-cvc">CVC
<input type="text" id="adyen-encrypted-form-cvc" value="737" size="4" autocomplete="off"
data-encrypted-name="cvc" />
</label>
</div>
<div class="field">
<label for="adyen-encrypted-form-expiry-month">Expiration Month (MM)
<input type="text" value="06" id="adyen-encrypted-form-expiry-month" size="2"
autocomplete="off" data-encrypted-name="expiryMonth" /> /
</label>
<label for="adyen-encrypted-form-expiry-year">Expiration Year (YYYY)
<input type="text" value="2016" id="adyen-encrypted-form-expiry-year" size="4"
autocomplete="off" data-encrypted-name="expiryYear" />
</label>
</div>
<div class="field">
<input type="hidden" id="adyen-encrypted-form-expiry-generationtime" value="generate-thisserver-side" data-encrypted-name="generationtime" />
<input type="submit" value="Submit" />
</div>
</fieldset>
</form>
<!-- How to use the Adyen encryption client-side JS library →
<script src="../js/adyen.encrypt.min.js"></script>
<script>
// generate time client side for testing... Don't deploy on a real integration!!!
document.getElementById('adyen-encrypted-form-expiry-generationtime').value = new
Date().toISOString();
+
+
+
+
+
+
+
// the form element to encrypt
var form
= document.getElementById('adyen-encrypted-form');
// the public key – Replace as explained in section 2.3.3
var key
= "10001|80C7821C961865FB4AD23F172E220F819A5CC7B9956BC3458E2788"
"F9D725B07536E297B89243081916AAF29E26B7624453FC84CB10FC7DF386"
"31B3FA0C2C01765D884B0DA90145FCE217335BCDCE4771E30E6E5630E797"
"EE289D3A712F93C676994D2746CBCD0BEDD6D29618AF45FA6230C1D41FE1"
"DB0193B8FA6613F1BD145EA339DAC449603096A40DC4BF8FACD84A5D2CA5"
"ECFC59B90B928F31715A7034E7B674E221F1EB1D696CC8B734DF7DE2E309"
"E6E8CF94156686558522629E8AF59620CBDE58327E9D84F29965E4CD0FAF"
"A38C632B244287EA1F7F70DAA445D81C216D3286B09205F6650262CAB415"
43 / 68
API Manual
+ "5F024B3294A933F4DC514DE0B5686F6C2A6A2D";
var options = {};
// the form will be encrypted before it is submitted
adyen.encrypt.createEncryptedForm( form, key, options);
</script>
</body>
</html>
44 / 68
API Manual
Appendix F: Integration Example – CSE
A full integration example along with the javascript library can be found here:
https://github.com/adyenpayments/client-side-encryption/tree/master/html-js
Identify your form with an “id” attribute
<form method="POST" action="posthandler.action" id="adyen-encrypted-form">
Input felds for the card data should not have a “name” attribute
<input type="text" value="" size="20" autocomplete="off" data-encrypted-name="number">
Add a hidden generationtime feld with the current time on server
The format of this should be in the ISO 8601 standard format for XML as YYYY-MM-DDTHH:mm:ss.sssZ. For example,
2013-04-26T14:02:30.668Z.
It is important to not rely on the client's time, especially in the LIVE environment, which may be incorrect as the encrypted
data is only usable within a 24 hour period of this time.
<input type="hidden" value=”GENERATE_ON_SERVER” id="generationtime"
name=”generationtime”>
data-encrypted-
The JavaScript
Include the JavaScript:
<script src="js/adyen.encrypt.min.js"></script>
var form
var key
= document.getElementById('adyen-encrypted-form'); // the form element to encrypt
= "10001|80C7821C961865FB4AD23F172E220F819A5CC7B9956BC3458E2788"
…
+ "5F024B3294A933F4DC514DE0B5686F6C2A6A2D";
// the public key
adyen.encrypt.createEncryptedForm( form, key ); // the form will be encrypted before it is
submitted
Adjusting the default form post behaviour (e.g. A JAX)
You can change the behaviour of the library by adding options to the “createEncryptedForm()”:
For example, change the name of the encrypted data, the default is “adyen-encrypted-data” and submit the form using
A JAX rather than the default:
var name
= 'fieldnameofyourchoosing';
adyen.encrypt.createEncryptedForm( form, key {
name : name,
onsubmit : function(e) {
… Your AJAX Code Here …
e.preventDefault();
}
});
45 / 68
API Manual
Appendix G: Integration Example – Server Side (SOAP)
<soap:Body>
<additionalData xmlns="http://payment.services.adyen.com">
<entry xmlns="http://payment.services.adyen.com">
<key xmlns="http://payment.services.adyen.com"
xsi:type="xsd:string">card.encrypted.json</key>
<value xmlns="http://payment.services.adyen.com" xsi:type="xsd:string">Your generated
key string from the JavaScript encryption...
adyenjs_0_1_1$eGcJxidHkg5LYQ...6LUio9RipqyTBu11MJIC+rlMYxituYCT7A9yDeF2Rlv2I56KOAap66tTm2uZkto4PKR
W4YCA8dZYQ==</value>
</entry>
</additionalData>
</amount>
<merchantAccount
</ns1:authorise>
</soap:Body>
</soap:Envelope>
46 / 68
API Manual
Appendix H: Integration Example – Server Side (REST with
cURL)
Submit a charge
curl --user 'username:password' https://pal-test.adyen.com/pal/adapter/httppost \
--data-urlencode 'action=Payment.authorise' \
--data-urlencode 'paymentRequest.amount.currency=EUR' \
--data-urlencode 'paymentRequest.amount.value=1234' \
--data-urlencode 'paymentRequest.merchantAccount=SupportAdyenTest' \
--data-urlencode 'paymentRequest.reference=Example Order 1' \
--data-urlencode
'paymentRequest.additionalData.card.encrypted.json=adyenjs_0_1_1$eGcJxidHkg5LYQ...6LUio9RipqyTBu11
MJIC+rlMYxituYCT7A9yDeF2Rlv2I56KOAap66tTm2uZkto4PKRW4YCA8dZYQ=='
Submit initial charge and store customer
--data-urlencode 'paymentRequest.recurring.contract=RECURRING' \
--data-urlencode 'paymentRequest.shopperReference=user123' \
--data-urlencode '[email protected]' \
--data-urlencode
'paymentRequest.additionalData.card.encrypted.json=adyenjs_0_1_1$kj7nlobE1rlC2...iaE/cY878H+Op'
------------Response ---paymentResult.authCode=98356
paymentResult.pspReference=9913642236790892
paymentResult.resultCode=Authorised
-------------------------
List recurring details/cards for customer
--data-urlencode 'action=Recurring.listRecurringDetails' \
--data-urlencode 'recurringDetailsRequest.merchantAccount=SupportAdyenTest' \
--data-urlencode 'recurringDetailsRequest.recurring.contract=RECURRING'
--data-urlencode 'recurringDetailsRequest.shopperReference=user123' \
------------Response ---recurringDetailsResult.shopperReference=user123
recurringDetailsResult.creationDate=2013-03-25T13:23:14+01:00
recurringDetailsResult.lastKnownShopperEmail=john.doe@example.com
recurringDetailsResult.details.0.variant=mc
recurringDetailsResult.details.0.recurringDetailReference=9913642141960010
recurringDetailsResult.details.0.creationDate=2013-03-25T13:23:16+01:00
recurringDetailsResult.details.0.card.number=1111
recurringDetailsResult.details.0.card.expiryMonth=6
recurringDetailsResult.details.0.card.expiryYear=2016
recurringDetailsResult.details.0.card.holderName=John Doe
-------------------------
47 / 68
API Manual
Submit a recurring charge
--data-urlencode 'paymentRequest.shopperReference=user123' \
--data-urlencode 'paymentRequest.shopperInteraction=ContAuth' \
--data-urlencode 'paymentRequest.recurring.contract=RECURRING' \
--data-urlencode 'paymentRequest.selectedRecurringDetailReference=9913642141960010'
------------Response ---paymentResult.authCode=75682
paymentResult.pspReference=9913642244711617
paymentResult.resultCode=Authorised
-------------------------
48 / 68
API Manual
Appendix I: Authorise3d Request
Authorise3d Request
<soap:Body>
<ns1:authorise3d xmlns:ns1="http://payment.services.adyen.com">
<ns1:paymentRequest3d>
<browserInfo xmlns="http://payment.services.adyen.com">
<acceptHeader
xmlns="http://common.services.adyen.com">text/html,appli.../*;q=0.8</acceptHeader>
<userAgent xmlns="http://common.services.adyen.com">Mozilla/5.0 ...
Firefox/3.0</userAgent>
</browserInfo>
<md xmlns="http://payment.services.adyen.com">31h..........vOXek7w=</md>
<merchantAccount
<paResponse xmlns="http://payment.services.adyen.com">eNqtmF........wGVA4Ch</paResponse>
</ns1:paymentRequest3d>
</ns1:authorise3d>
</soap:Body>
</soap:Envelope>
The response to this request is the same as a non-3-D Secure payment request and the resultCode will be one of
Authorised, Refused or Error.
49 / 68
API Manual
Appendix J: Payment Request with Installments
<?xml version="1.0" encoding="UTF-8"?>
<soap:Body>
<currency xmlns="http://common.services.adyen.com">BRL</currency>
</amount>
<cvc>737</cvc>
<number>4111111111111111</number>
</card>
<installments xmlns="http://payment.services.adyen.com">
<value xmlns=4</value>
</installments>
<merchantAccount
</ns1:authorise>
</soap:Body>
</soap: Envelope>
&paymentRequest.amount.currency=BRL&paymentRequest.amount.value=2000&paymentRequest.card.cvc=737
&paymentRequest.card.expiryMonth=06&paymentRequest.card.expiryYear=2016
&paymentRequest.card.holderName=Adyen+Test&paymentRequest.card.number=4111111111111111&paymentRequ
est.merchantAccount=SupportAdyenTest
&paymentRequest.reference=test1234&paymentRequest.installments.value=2
50 / 68
API Manual
Appendix K: CVC/CVV and AVS Result Values
CVC/CVV Result Values
0
Unknown
1
Matches
2
Doesn't match
3
Not checked
4
No CVC/CVV provided, but was required
5
Issuer not certifed for CVC/CVV
6
No CVC/CVV provided
AVS Result
51 / 68
API Manual
0
Unknown
1
Address matches, postal code doesn't
2
Neither postal code nor address match
3
AVS unavailable
4
AVS not supported for this card type
5
No AVS data provided
6
Postal code matches, address doesn't match
7
Both postal code and address match
8
Address not checked, postal code unknown
9
Address matches, postal code unknown
10
Address doesn't match, postal code unknown
11
Postal code not checked, address unknown
12
Address matches, postal code not checked
13
Address doesn't match, postal code not checked
14
Postal code matches, address unknown
15
Postal code matches, address not checked
16
Postal code doesn't match, address unknown
17
Postal code doesn't match, address not checked
18
Neither postal code nor address were checked
19
Name and postal code matches
20
Name, address and postal code matches
21
Name and address matches
22
Name matches
23
Postal code matches, name doesn't match
24
Both postal code and address matches, name doesn't match
25
Address matches, name doesn't match
26
Neither postal code, address nor name matches
Appendix L: ACH Payment Request
<soap:Body>
<currency xmlns="http://common.services.adyen.com">USD</currency>
</amount>
<bankAccount xmlns="http://payment.services.adyen.com">
<bankLocationId>011000028</bankLocationId>
<countryCode>US</countryCode>
<ownerName>Andrews</ownerName>
<bankAccountType>C</bankAccountType>
</bankAccount>
<merchantAccount
<shopperReference xmlns="http://payment.services.adyen.com">111541</shopperReference>
<shopperInteraction
xmlns="http://payment.services.adyen.com">Ecommerce</shopperInteraction>
</ns1:authorise>
</soap:Body>
</soap:Envelope>
action=Payment.authorise&paymentRequest.amount.currency=USD&paymentRequest.amount.value=200&paymen
tRequest.merchantAccount=SupportAdyenTest&paymentRequest.reference=testReference1234&paymentReques
t.bankAccount.bankAccountNumber=11111111111111111&paymentRequest.bankAccount.bankLocationId=011000
028&paymentRequest.bankAccount.countryCode=US&paymentRequest.bankAccount.ownerName=Andrews&payment
Request.bankAccount.bankAccountType=C&paymentRequest.shopperIP=212.14.111.12&paymentRequest.shoppe
rReference=111541&paymentRequest.shopperInteraction=Ecommerce
52 / 68
API Manual
Appendix M: SEPA Direct Debit One-of Payment Request
and Response
One-Of Payment Request
<soap:Body>
<ns1:amount>
</ns1:amount>
<ns1:bankAccount>
<ns1:bic>RABONL2U</ns1:bic>
<ns1:iban>NL48RABO0132394782</ns1:iban>
<ns1:ownerName>Klaas T. Jansen</ns1:ownerName>
<ns1:countryCode>NL</ns1:countryCode>
</ns1:bankAccount>
<ns1:merchantAccount>SupportAdyenTest</ns1:merchantAccount>
<ns1:reference>Your Reference Here</ns1:reference>
<ns1:shopperEmail>[email protected]</ns1:shopperEmail>
<ns1:shopperReference>TheShopperReference</ns1:shopperReference>
<ns1:shopperIP>10.10.100.200</ns1:shopperIP>
<ns1:shopperStatement>UW ORDER 122345677889</ns1:shopperStatement>
<ns1:selectedBrand>sepadirectdebit</ns1:selectedBrand>
</ns1:authorise>
</soap:Body>
</soap:Envelope>
53 / 68
API Manual
One-Of Payment Response
<soap:Body>
<ns1:paymentResult>
<additionalData xmlns="http://payment.services.adyen.com">
<entry>
<key xsi:type="xsd:string">sepadirectdebit.dateOfSignature</key>
<value xsi:type="xsd:string">2013-11-28</value>
</entry>
<entry>
<key xsi:type="xsd:string">sepadirectdebit.sequenceType</key>
<value xsi:type="xsd:string">First</value>
</entry>
<entry>
<key xsi:type="xsd:string">sepadirectdebit.mandateID</key>
<value xsi:type="xsd:string">9913856361050084</value>
</entry>
</additionalData>
<authCode xmlns="http://payment.services.adyen.com" xsi:nil="true"/>
<dccAmount xmlns="http://payment.services.adyen.com" xsi:nil="true"/>
<dccSignature xmlns="http://payment.services.adyen.com" xsi:nil="true"/>
<fraudResult xmlns="http://payment.services.adyen.com" xsi:nil="true"/>
<issuerUrl xmlns="http://payment.services.adyen.com" xsi:nil="true"/>
<md xmlns="http://payment.services.adyen.com" xsi:nil="true"/>
<paRequest xmlns="http://payment.services.adyen.com" xsi:nil="true"/>
<pspReference xmlns="http://payment.services.adyen.com">9913856361050084</pspReference>
<refusalReason xmlns="http://payment.services.adyen.com" xsi:nil="true"/>
<ns1:resultCode>Received</ns1:resultCode>
</soap:Body>
</soap:Envelope>
For the feld sepadirectdebit.sequenceType, if this is the frst payment the value will be “First. If this is a subsequent
payment, the value will be 'Recurring'.
54 / 68
API Manual
Appendix N: SEPA Direct Debit Recurring Payment
Request
<soap:Body>
<ns1:amount>
</ns1:amount>
<ns1:merchantAccount>SupportAdyenTest</ns1:merchantAccount>
<ns1:reference>Your Reference Here</ns1:reference>
<ns1:shopperEmail>[email protected]</ns1:shopperEmail>
<ns1:shopperReference>TheShopperReference</ns1:shopperReference>
<ns1:shopperInteraction>ContAuth</ns1:shopperInteraction>
<ns1:recurring>
<ns1:contract>RECURRING</ns1:contract>
</ns1:recurring>
<ns1:selectedRecurringDetailRetail>LATEST</ns1:selectedRecurringDetailRetail>
<ns1:selectedBrand>sepadirectdebit</ns1:selectedBrand>
</ns1:authorise>
</soap:Body>
</soap:Envelope>
55 / 68
API Manual
Appendix O: Incasso Payment Request
<soap:Body>
</amount>
<bankAccount xmlns="http://payment.services.adyen.com">
<bankName>POSTBANK</bankName>
<countryCode>NL</countryCode>
<ownerName>Test</ownerName>
</bankAccount>
<merchantAccount
<shopperInteraction xmlns="http://payment.services.adyen.com">UW ORDER
122345677889</shopperInteraction>
</ns1:authorise>
</soap:Body>
</soap:Envelope>
56 / 68
API Manual
Appendix P: Boleto SOAP API Payment Request and
Response
<soap:Body>
<authorise xmlns="http://payment.services.adyen.com">
<paymentRequest>
<amount>
<ns1:currency xmlns:ns1="http://common.services.adyen.com">BRL</ns1:currency>
<ns2:value xmlns:ns2="http://common.services.adyen.com">1000</ns2:value>
</amount>
<billingAddress>
<ns3:city xmlns:ns3="http://common.services.adyen.com">São Paulo</ns3:city>
<ns4:country xmlns:ns4="http://common.services.adyen.com">BR</ns4:country>
<ns5:houseNumberOrName
xmlns:ns5="http://common.services.adyen.com">999</ns5:houseNumberOrName>
<ns6:postalCode xmlns:ns6="http://common.services.adyen.com">04787910</ns6:postalCode>
<ns7:stateOrPrivince
xmlns:ns7="http://common.services.adyen.com">SP</ns7:stateOrPrivince>
<ns8:street xmlns:ns8="http://common.services.adyen.com">Roque Petroni Jr</ns8:street>
</card>
<deliveryDate xmlns="http://payment.services.adyen.com">2013-1029T23:00:00.000Z</deliveryDate>
<merchantAccount
<reference xmlns="http://payment.services.adyen.com">Teste Boleto</reference>
<selectedBrand
xmlns="http://payment.services.adyen.com">boletobancario_santander</selectedBrand>
<shopperName xmlns="http://payment.services.adyen.com">
<ns9:firstName xmlns:ns9="http://common.services.adyen.com">José</ns9:firstName>
<ns10:lastName xmlns:ns10="http://common.services.adyen.com">Silva</ns10:lastName>
</shopperName>
<shopperStatement>Aceitar o pagamento até 15 dias após o vencimento.
Não cobrar juros.
Não aceitar o pagamento com cheque.</shopperStatement>
<socialSecurityNumber>56861752509</socialSecurityNumber>
</paymentRequest>
</ns1:authorise>
</soap:Body>
</soap:Envelope>
57 / 68
API Manual
SOAP Payment Response
<soap:Body>
<ns1:paymentResult>
<additionaldata xmlns="http://payment.services.adyen.com">
<entry>
<key xsi:type="xsd:string">boletobancario.url</key>
<value xsi:type="xsd:string">https://test.adyen.com/hpp/generationBoleto.shtml?
data=AgABAQAk5QYbuNl9TiV63c5KeLTvXpB03Ml3krv%2FtwYj....2FFq3920vVWRd5HKHT96mCdVXyo4Gzq
%2BTkzNbmT2XcgFf%2FwhYkU4%3D</value>
</entry>
<entry>
<key xsi:type="xsd:string">boletobancario.data</key>
<value
xsi:type="xsd:string">AgABAQAk5QYbuNl9TiV63c5KeLTvXpB03Ml3krv/twYj....2FFq3920vVWRd5HKHT96mCdVXyo4
Gzq+TkzNbmT2XcgFf/whYkU4=</value>
</entry>
<entry>
<key xsi:type="xsd:string">boletobancario.expirationDate</key>
</entry>
<entry>
<key xsi:type="xsd:string">boletobancario.dueDate</key>
</entry>
</additionaldata>
<pspReference xmlns="http://payment.services.adyen.com">8813760397300101</authCode>
<resultCode xmlns="http://payment.services.adyen.com">Received</authCode>
</soap:Body>
</soap:Envelope>
58 / 68
API Manual
Appendix Q: Boleto REST API Payment Request and
Response
&paymentRequest.amount.currency=BRL&paymentRequest.amount.value=1000&paymentRequest.billingAddress
.city=Sao+Paulo&paymentRequest.billingAddress.country=BR&paymentRequest.billingAddress.houseNumber
OrName=999&paymentRequest.billingAddress.postalCode=04787910&paymentRequest.billingAddress.stateOr
Province=SP&paymentRequest.billingAddress.street=Rua+Roque+Petroni+Jr&paymentRequest.deliveryDate=
2013-0815T02:00:00+02:00&paymentRequest.merchantAccount=SupportAdyenTest&paymentRequest.reference=Teste+B
oleto&paymentRequest.selectedBrand=boletobancario_santander&paymentRequest.shopperName.firstName=J
osé&paymentRequest.shopperName.lastName=Silva&paymentRequest.shopperStatement=Aceitar+o+pagamento+
até+15+dias+após+o+vencimento.%0A+Não+cobrar+juros.
+Não+aceitar+o+pagamento+com+cheque.&paymentRequest.socialSecurityNumber=65468766205
REST Payment Response
paymentResult.additionalData.boletobancario.url=https://test.adyen.com/hpp/generationBoleto.shtml?
data=AgABAQClZUyg1NqsD7nN5X1uqN4mabJ7A3FH5LgAUbqDnJ6EAQlnSAVL%2Bu7eWIXY%2Fo%2B7F0v04ZEnh6VR%2F
%2BIAUfJoMQba2uHb2%2BqezXU
%2FhgULKuFov7s2ZnwmszAuuHgE6JvahvWtAygC5lnpLEgw34pp7z8Vf2hAQYO9mvELei6ZR8S6DMxVTObYGE6r
%2FanhX1ucteKztIR79zv1wWWzV%2FbccQIqgOEp5b8AYU6mwOlbm0oP2lPZofq4CFAQfs
%2FROyBk0JBQlQDaZHQRmY8YP3236nD6eEr4cBEy6MpULl8w0iin39NxXGsi7OCmuQDe2w1Fy
%2F40Iv6AA2sar3JTo4Ap3eraC6PEN8s5%2BSoOB5MO
%2BfpFbRSfFeSHGh9L3%2FwzuxaXCHopNfwjjgx6aJEVv1FmaPzyVYm9kB7%2B
%2F1IpaxzBIp6nTh5VSMp8iJOyOccCoV4e7Qv6SKNDkvT5lc2KPXg6jUC4tQJWyFFbvgV55rlQojjRecQfLwCiQ51tONSyaw2Q
LewemJJys9Q2AyIXYemGUXdzYAORNlSLJkTQdkoQZKdMwuOx4LDPFkNQuzHLlg4Xg
%2BpWYhgSz0TEZJrS83voNSRTbrIwOPN3&paymentResult.pspReference=8513763283942198&paymentResult.additi
onalData.boletobancario.dueDate=2013-08-15&
paymentResult.additionalData.boletobancario.data=AgABAQClZUyg1NqsD7nN5X1uqN4mabJ7A3FH5LgAUbqDnJ6EA
QlnSAVL+u7eWIXY/o+7F0v04ZEnh6VR/
+IAUfJoMQba2uHb2+qezXU/hgULKuFov7s2ZnwmszAuuHgE6JvahvWtAygC5lnpLEgw34pp7z8Vf2hAQYO9mvELei6ZR8S6DMx
VTObYGE6r/anhX1ucteKztIR79zv1wWWzV/bccQIqgOEp5b8AYU6mwOlbm0oP2lPZofq4CFAQfs/ROyBk0JBQlQDaZHQRmY8YP
3236nD6eEr4cBEy6MpULl8w0iin39NxXGsi7OCmuQDe2w1Fy/40Iv6AA2sar3JTo4Ap3eraC6PEN8s5+SoOB5MO+fpFbRSfFeS
HGh9L3/wzuxaXCHopNfwjjgx6aJEVv1FmaPzyVYm9kB7+/1IpaxzBIp6nTh5VSMp8iJOyOccCoV4e7Qv6SKNDkvT5lc2KPXg6j
UC4tQJWyFFbvgV55rlQojjRecQfLwCiQ51tONSyaw2QLewemJJys9Q2AyIXYemGUXdzYAORNlSLJkTQdkoQZKdMwuOx4LDPFkN
QuzHLlg4Xg+pWYhgSz0TEZJrS83voNSRTbrIwOPN3&
paymentResult.additionalData.boletobancario.expirationDate=2013-0822&paymentResult.resultCode=Received
59 / 68
API Manual
Appendix R: Sample Boleto Forms
Default Form
60 / 68
API Manual
Custom Form
61 / 68
API Manual
Appendix S: SOAP Notifcation Request and Response
SOAP Notifcation Request
<soap:Body>
<ns1:sendNotification xmlns:ns1="http://notification.services.adyen.com">
<ns1:Notification>
<live xmlns="http://notification.services.adyen.com">false</live>
<notificationItems xmlns="http://notification.services.adyen.com">
<NotificationRequestItem>
<additionalData xsi:ns1="true"/>
<amount>
</amount>
<eventDate>2009-01-01T01:02:01.111+02:00</eventDate>
<merchantReference>YourMerchantReference1</merchantReference>
<operations>
<string>CANCEL</string>
<string>CAPTURE</string>
<string>REFUND</string>
</operations>
<originalReference xsi:ns1="true"/>
<paymentMethod>visa</paymentMethod>
<reason>01234:1111:12/2012</reason>
</NotificationRequestItem>
<NotificationRequestItem>
<additionalData xsi:ns1="true"/>
<amount>
</amount>
<eventDate>2009-01-01T01:01:01.111+02:00</eventDate>
<merchantAccountCode>YourMerchantAccount</merchantAccountCode>
<merchantReference>YourMerchantReference2</merchantReference>
<operations>
<string>CANCEL</string>
<string>CAPTURE</string>
<string>REFUND</string>
</operations>
<originalReference xsi:ns1="true"/>
<paymentMethod>mc</paymentMethod>
<reason>56789:1111:12/2012</reason>
</NotificationRequestItem>
</ns1:Notification>
</ns1:sendNotification>
</soap:Body>
</soap:Envelope>
62 / 68
API Manual
SOAP Notifcation Response
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ns1:sendNotificationResponse xmlns:ns1="http://notification.services.adyen.com"
xmlns:ns2="http://common.services.adyen.com">
<notificationResponse>[accepted]</notificationResponse>
</ns1:sendNotificationResponse>
</soap:Body>
</soap:Envelope>
63 / 68
API Manual
Appendix T: REST Notifcation Request and Response
REST Notifcation Request
eventDate=2012-0925T13%3A41%3A33.81Z&reason=2120%3A1111%3A12%2F2012&originalReference=&merchantReference=reference_
415579&currency=EUR&pspReference=8613485804662747&merchantAccountCode=SupportAdyenTest&eventCode=A
UTHORISATION&value=24205&operations=CANCEL%2CCAPTURE
%2CREFUND&success=true&paymentMethod=mc&live=false
REST Notifcation Response
notificationResponse=&sBaccepted%5D
64 / 68
API Manual
Appendix U: Fault Codes
Error Code
Fault
000
Unknown
010
Not allowed
100
No amount specifed
101
Invalid card number
102
Unable to determine variant
103
CVC is not the right length
104
Billing address problem
105
Invalid paRes from issuer
106
This session was already used previously
107
Recurring is not enabled
108
Invalid bankaccount number
109
Invalid variant
110
BankDetails missing
111
Invalid BankCountryCode specifed
112
This bank country is not supported
113
No InvoiceLines provided
114
Received a incorrect InvoiceLine
115
Total amount is not the same as the sum of the lines
116
Invalid date of birth
117
Invalid billing address
118
Invalid delivery address
119
Invalid shopper name
120
ShopperEmail is missing
121
ShopperReference is missing
122
PhoneNumber is missing
123
The PhoneNumber should be mobile
124
Invalid PhoneNumber
125
Invalid recurring contract specifed
126
Bank Account or Bank Location Id not valid or missing
127
Account holder missing
128
Card Holder Missing
129
Expiry Date Invalid
130
Reference Missing
131
Billing address problem (City)
132
Billing address problem (Street)
65 / 68
API Manual
Error Code
Fault
133
Billing address problem (HouseNumberOrName)
134
Billing address problem (Country)
135
Billing address problem (StateOrProvince)
136
Failed to retrieve OpenInvoiceLines
137
Invalid amount specifed
138
Unsupported currency specifed
139
Recurring requires shopperEmail and shopperReference
140
Invalid expiryMonth[1..12] / expiryYear[>2000], or before now
141
Invalid expiryMonth[1..12] / expiryYear[>2000]
142
Bank Name or Bank Location not valid or missing
143
Submitted total iDeal merchantReturnUrl length is {0}, but max size is {1} for this request
144
Invalid startMonth[1..12] / startYear[>2000], or in the future
145
Invalid issuer countrycode
146
Invalid social security number
147
Delivery address problem (City)
148
Delivery address problem (Street)
149
Delivery address problem (HouseNumberOrName)
150
Delivery address problem (Country)
151
Delivery address problem (StateOrProvince)
152
Invalid number of installments
153
Invalid CVC
154
No additional data specifed
155
No acquirer specifed
156
No authorisation mid specifed
157
No felds specifed
158
Required feld {0} not specifed
159
Invalid number of requests
160
Not allowed to store Payout Details
161
Invalid iban
162
Inconsistent iban
163
Invalid bic
170
Generation Date required but missing
171
Unable to parse Generation Date
172
Encrypted data used outside of valid time period
173
Unable to load Private Key for decryption
174
Unable to decrypt data
175
Unable to parse JSON data
66 / 68
API Manual
Error Code
Fault
180
Invalid shopperReference
181
Invalid shopperEmail
182
Invalid selected brand
183
Invalid recurring contract
184
Invalid recurring detail name
185
Invalid additionalData
186
Missing additionalData feld
187
Invalid additionalData feld
188
Invalid pspEchoData
600
No InvoiceProject provided
601
No InvoiceBatch provided
602
No creditorAccount specifed
603
No projectCode specifed
604
No creditorAccount found
605
No project found
606
Unable to create InvoiceProject
607
InvoiceBatch already exists
608
Unable to create InvoiceBatch
609
InvoiceBatch validity period exceeded
690
Error while storing debtor
691
Error while storing invoice
692
Error while checking if invoice already exists for creditorAccount
693
Error while searching invoices
694
No Invoice Confguration confgured for creditAccount
695
Invalid Invoice Confguration confgured for creditAccount
800
Contract not found
801
Too many PaymentDetails defned
802
Invalid contract
803
PaymentDetail not found
804
Failed to disable
805
RecurringDetailReference not available for provided recurring-contract
806
No applicable contractTypes left for this payment-method
901
Invalid Merchant Account
902
Shouldn't have gotten here without a request!
903
Internal error
904
Unable To Process
905
Payment details are not supported
67 / 68
API Manual
Error Code
Fault
906
Invalid Request: Original pspReference is invalid for this environment!
950
Invalid AcquirerAccount
951
Confguration Error (acquirerIdentifcation)
952
Confguration Error (acquirerPassword)
953
Confguration Error (apiKey)
954
Confguration Error (redirectUrl)
955
Confguration Error (AcquirerAccountData)
956
Confguration Error (currencyCode)
957
Confguration Error (terminalId)
958
Confguration Error (serialNumber)
959
Confguration Error (password)
960
Confguration Error (projectId)
961
Confguration Error (merchantCategoryCode)
962
Confguration Error (merchantName)
68 / 68
API Manual

API Manual Contact details

Transcription

Similar documents

Updated* Needs List

The Nanohana Eco-Project originated in the “Soap Movement” for

THE SCOOP BEHIND

Ask About Our $10.00 Mufflers

Gabe Westmaas Rackspace @westmaas

Homemade Laundry Soap

Lutheran Child & Family Services Wish List

Sze Wong | CEO | Zerion Software, Inc.

Why soap? BON [Bio Organic & Natural]

soap_csharp_labstats_5.