Recurring payments manual Copyright (c) Adyen B.V. 2014

Transcription

Recurring payments
manual
Version: 2.30
Copyright (c) Adyen B.V. 2014
1. Introduction ................................................................................................................................................ 6 2. What is a recurring contract? .................................................................................................................... 7 2.1. Recurring vs One-Click ................................................................................................................................................................................. 7 2.2. Standard workflow ....................................................................................................................................................................................... 7 3. Creating a recurring contract ................................................................................................................... 8 4. Retrieving the recurring contract details ................................................................................................ 9 4.1. listRecurringDetails request .......................................................................................................................................................................... 9 4.2. listRecurringDetails response ....................................................................................................................................................................... 9 4.3. tokenLookup service ................................................................................................................................................................................... 10 5. Submitting a recurring transaction ........................................................................................................ 11 5.1. Payment request ........................................................................................................................................................................................ 11 5.1.1. One-Click payments .................................................................................................................................................................................11 5.1.2. Recurring payments .................................................................................................................................................................................11 5.2. Payment response ..................................................................................................................................................................................... 12 6. Updating stored details ........................................................................................................................... 13 7. Disabling a recurring contract ................................................................................................................ 14 7.1. Disable request .......................................................................................................................................................................................... 14 7.2. Disable response ........................................................................................................................................................................................ 14 8. Supported payment methods ................................................................................................................. 15 8.1. card .............................................................................................................................................................................................................. 15 8.2. directdebit_NL – to be deprecated 1 August 2014 ............................................................................................................................... 15 st
8.3. elv – to be deprecated 1 August 2014 ................................................................................................................................................... 15 st
8.4. directEbanking ............................................................................................................................................................................................ 15 8.5. giropay ......................................................................................................................................................................................................... 15 8.6. iDEAL ............................................................................................................................................................................................................ 15 8.7. paypal .......................................................................................................................................................................................................... 16 8.8. SEPA Direct Debit ....................................................................................................................................................................................... 16 9. Account Updater ....................................................................................................................................... 17 9.1. Requesting updates on stored cards ....................................................................................................................................................... 17 9.2. Responses to update requests ................................................................................................................................................................. 18 9.3. Using the updated details ......................................................................................................................................................................... 19 10. FAQ ........................................................................................................................................................... 20 Appendix A: TEST and LIVE URLs ................................................................................................................. 21 Appendix B: Complete workflow example ................................................................................................ 22 Step 1: First initial recurring payment............................................................................................................................................................. 22 Step 2: listRecurringDetails for a shopper ........................................................................................................................................................ 22 Step 3: Subsequent payment ........................................................................................................................................................................... 23 Step 4: Storing a second recurring detail ....................................................................................................................................................... 24 Step 5: Second subsequent payment ............................................................................................................................................................. 25 Appendix C: REST example of a listRecurringDetails request and response ........................................... 27 Appendix D: REST example of a recurring payment request and response .......................................... 28 Appendix E: SOAP example for updating stored details .......................................................................... 29 Appendix F: REST example for updating stored details ........................................................................... 30 Appendix G: SOAP example of a disable recurring contract request and response ............................ 31 Appendix H: REST example of a disable recurring contract request and response ............................. 32 Appendix I: SOAP account updater request and response using card data .......................................... 33 Appendix J: SOAP account updater request and response using token data ....................................... 34 2
Recurring payments manual
Appendix K: Sample Account Updater batch file ...................................................................................... 35 Appendix L: SOAP tokenLookup request and response ........................................................................... 36 Appendix M: SOAP listRecurringDetails response with updated expiry date ......................................... 37 Appendix N: REST listRecurringDetails response with updated expiry date .......................................... 38 Appendix O: SOAP listRecurringDetails response with updated card information ............................... 39 Appendix P: REST listRecurringDetails response with updated card information ................................. 40 Appendix Q: SOAP payment request with updated expiry date ............................................................. 41 Appendix R: REST payment request with updated expiry date .............................................................. 42 Appendix S: SOAP payment request with new card details .................................................................... 43 Appendix T: REST payment request with new card details ..................................................................... 44 3
Changelog
Version
Date
Changes
•
Updated document to conform to Adyen brand guidelines
•
Added account updater section and appendices
•
Updated One-Click definition
•
Updated supported payment methods
2012-10-03
•
Updated Chapter 5 to always use a selectedRecurringDetailReference
2.28
2012-05-08
•
Added information about PayPal with list recurring details calls
•
Expanded Example 3 (response details)
2.27
2012-01-10
•
Clarified where to send ONECLICK subsequent payments
2.26
2011-12-06
•
Removed tokenisation functionality
2.25
2011-11-22
•
Added information about PayPal recurring limits
2.24
2011-08-31
•
Added Appendix C with sample workflow code
2.23
2011-08-22
•
Clearer definition of ONECLICK functionality
•
Added new payment methods that can be recurring
2.22
2011-08-03
•
Added shopperStatement field
2.21
2011-06-14
•
Added deprecation notice for directDebit recurring requests
•
Moved text associated with deprecated code to new Appendix
2.20
2011-04-08
•
Corrected namespace for contract parameter in Example 5
•
Added disclaimer about SOAP examples
2.19
2010-10-27
•
Added recurringDetailReference field to storeToken method
•
Added information about validation to storeToken method
•
Corrected mistakes about recharge & recurring detail references
•
Added need for separate skin when tokenising via HPP
•
Added Changelog and Audience sections
•
Manual reviewed for English and layout consistency
2.30
2.29
2014-09-04
2.18
2010-09-17
2.17
2010-08-05
2.16
2010-07-13
•
Corrected names of SOAP elements to match WSDL
2.15
2010-05-18
•
Added storeToken using HPP
2.14
2010-04-19
•
Add storeToken examples
4
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://www.adyen.com/home/support/manuals.html
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
1. Introduction
The purpose of this manual is to enable you to create and submit recurring payments to the Adyen Payment System. Recurring
payments re-use payment details, previously stored by the shopper, to complete the payment.
In the following chapters we cover how you can:
Create a recurring contract using an initial payment
•
•
•
•
•
•
Retrieve the recurring contracts for a shopper
Submit a recurring transaction
Update stored details
Deactivate a recurring contract or detail
Submit Account Updater requests
Recurring payments are not enabled by default. Please contact the Adyen Support Team ([email protected]) if you would like to
start processing recurring payments.
This document is an addendum to the Adyen Merchant Integration Manual and will reference, without citation, concepts explained
there. The latest version of the Integration manual can be found here
https://www.adyen.com/home/support/manuals.html
Please note that API calls to Adyen may change, and are based on our WSDLs, listed in Appendix A.
To submit Recurring Payment requests you must supply authentication credentials. The username is
ws@Company.[YourCompanyAccount] and you set the password for this user in the Adyen Customer Area (CA) under “Settings” →
“Users”.
6
2. What is a recurring contract?
A recurring contract is a set of one or more recurring payment details linked to a unique shopper on your merchant account. The
contract is identified using the shopperReference and merchantAccount fields which are specified as part of the payment session, for
Hosted Payment Pages (HPP) or the payment request for Direct API.
The recurring details each have a unique 16 digit reference number called the recurringDetailReference. A recurring detail reference
number can be used in place of the actual payment details to submit a payment to the system.
Please note, the default recurring behaviour is for recurring contracts to be established and used within a single merchant
account. However, your account can be configured to allow you to use stored details across all merchant accounts associated with
your company account. Please contact the Adyen Support Team ([email protected]) if you would like to have this feature
enabled on your account.
2.1. Recurring vs One-Click
One-Click functionality gives the shopper the option to store their payment details with the merchant, within the Adyen environment.
The shopper makes this choice during their first payment by checking a checkbox.
For card payments, One-Click differs from Recurring as follows:
•
•
The shopper chooses whether their card data can be stored or not.
For subsequent transactions, the shopper is always present and must supply their card's security code (CVC/CVV).
One-Click has the advantage of ensuring full card authorisation takes place for each payment, including card security code checks
and 3D secure, if applicable, with the potential disadvantage that the shopper must be present for all payments.
2.2. Standard workflow
The usual workflow is as follows:
1.
Create your recurring contract by performing an initial Payment with the additional fields defined in section 3, ensuring that
you store the shopperEmail, shopperReference, and the recurringContract fields in your system for later use.
If you receive a successful AUTHORISATION notification for the payment then you know the recurring contract has been
created. You do not receive the recurringDetailReference at this time and need do nothing more in our system.
2.
When you're ready to process a subsequent payment, set the value of the selectedRecurringDetailReference to either:
1.
The recurringDetailReference returned from the list of all stored recurring details based on the shopperReference
provided in step 1.
2.
The word “LATEST”, which uses the most recently stored recurring detail.
Set other fields as per section 5, taking into account the recurringContract value that was set in step 1.
If the subsequent payment is successful you will receive an AUTHORISATION notification with success=”true”.
Please refer to section 8 for the list of supported payment methods.
Please refer to Appendix B for sample requests & responses for an entire workflow.
7
3. Creating a recurring contract
The payment session is set up like a regular payment. There are two previously optional fields that become compulsory and one new
field that needs to be provided in the payment session form.
•
shopperEmail (required)
The shopper's email address.
•
shopperReference (required)
An ID that uniquely identifies the shopper.
•
recurringContract (required)
The type of recurring contract to be used. One of:
o
ONECLICK
The shopper opts in to storing their card details for future use. The shopper is present for the subsequent
transaction, for cards the security code (CVC/CVV) is required.
o
RECURRING
Payment details are stored for future use. For cards, the security code (CVC/CVV) is not required for subsequent
payments.
o
ONECLICK, RECURRING
Payment details are stored for future use. This allows the use of the stored payment details regardless of whether
the shopper is on your site or not.
<input type="hidden" name="shopperEmail" value="[email protected]" />
<input type="hidden" name="shopperReference" value="grasshopper52" />
<input type="hidden" name="recurringContract" value="RECURRING" /> Please refer to Appendix C of the Adyen Integration Manual for details on how to include these values in the signature.
Please note:
•
The details will only be stored, and the recurringDetailReference created, if the payment is successful.
•
Shoppers are uniquely identified using the shopperReference parameter. It is very important that shoppers are securely
logged in on your site and that the shopperReference parameter cannot be modified by the shopper.
8
4. Retrieving the recurring contract details
When you want to submit a recurring payment, you may choose to query the Adyen system to return any stored payment details.
This is done by submitting a request to the listRecurringDetails action.
4.1. listRecurringDetails request
The request has the following fields:
•
merchantAccount
Your merchant account.
•
shopperReference
Your unique ID for the shopper. This shopperReference must be the same as the shopperReference used in the initial
payment.
•
recurring
o
contract
This should be the same value that was submitted using recurringContract in the payment where the recurring
contract was created. However, if “ONECLICK,RECURRING” was specified initially, then this field should be either
“ONECLICK” or “RECURRING” depending on whether or not you want the shopper to enter their card's security
code. Please refer to section 3 for more information.
Please refer to Step 2 of Appendix B for a SOAP example of a listRecurringDetails request and response.
Please refer to Appendix C for a REST example of a listRecurringDetails request and response.
4.2. listRecurringDetails response
The response will be a result with a list of zero or more details containing:
•
recurringDetailReference
The unique reference the details are stored under.
•
variant
The payment method, such as “mc”, “visa”, “ideal”, “paypal”.
•
creationDate
The date when the recurring details were created.
The recurring contracts are stored in the same object types that were used to submit the initial payment. Depending upon the
payment method, one or more fields may be blank or incomplete, for example CVC for card. Only one of the details below will be
returned per detail block, the others will be nil. For wallets (Paypal, Moneybookers/Skrill, Neteller) there is not a detail block.
•
card
A container for credit card data. This contains the following items:
o
expiryMonth
The expiration date's month written as a 2-digit string, padded with 0 if required, for example 03 or 12.
o
expiryYear
The expiration date's year written in full, for example 2008.
o
holderName
The card holder's name as embossed on the card.
o
number
The card number. Only the last 4 digits of the card number are returned.
o
cvc
The card validation code. This is the CVC2 code (for MasterCard), CVV2 (for Visa) or CID (for American Express).
The value will always be empty because it is not stored.
•
st
Elv – deprecated 1 August 2014
A container for elv data with the following fields:
o
bankLocation
The city in which the bank (branch) is located.
o
bankName
The name of the bank.
9
o
bankLocationId
The location ID (Bankleitzahl) of the bank.
o
accountHolderName
The name of the account holder.
o
bankAccountNumber
The account number (Kontonummer).
bank
•
A container for bankAccount data with the following fields:
o
bankAccountNumber
The account number.
o
bankLocationId
The location id of the bank. The field will be nil in most cases.
o
bankName
The name of the bank.
o
bic
The unique identification code for both financial and non-financial institutions. The field will be nil in most cases.
o
countryCode
The country of the bank details.
o
iban
The IBAN. The field will be nil in most cases.
o
ownerName
The account holder name.
Caching of the recurring details for a shopper is encouraged, however, please keep in mind that if the stored details are updated, the
recurringDetailReference for that detail will change and the cached entry should be invalidated.
Please refer to Step 2 of Appendix B for a SOAP example of a listRecurringDetails request and response.
Please refer to Appendix C for a REST example of a listRecurringDetails request and response.
4.3. tokenLookup service
In addition to the listRecurringDetails action, Adyen also offers the tokenLookup action which provides the ability to check the entered
card details to see if there is another stored token that has the same card details on file. This is currently only available via a SOAP
request.
Please refer to Appendix L for a SOAP tokenLookup API request and response.
10
5. Submitting a recurring transaction
You can submit a recurring payment using a specific recurringDetails record or by using the last created recurringDetails record. The
request for the recurring payment is done using a paymentRequest.
5.1. Payment request
You can submit a recurring payment by calling the authorise action on the Payment service with a paymentRequest. However, a OneClick payment session is set up like a regular payment and these additional fields are not required. Please refer to section 3.1 for
more information on setting up the payment.
5.1.1. One-Click payments
The paymentRequest is set up like a regular payment with a couple of differences:
•
card
The container for card data. This should contain the following items:
o
expiryMonth
The field should be null.
o
expiryYear
o
holderName
o
number
o
cvc
The card validation code. This is the CVC2 code (for MasterCard), CVV2 (for Visa) or CID (for American Express).
•
recurring
o
contract
If “ONECLICK,RECURRING” was specified initially, then this field should be “ONECLICK”. Please refer to section 3 for
more information.
•
shopperInteraction
Set to “Ecommerce”.
5.1.2. Recurring payments
The paymentRequest has the following fields:
•
selectedRecurringDetailReference
The recurringDetailReference you want to use for this payment. The value “LATEST” can be used to select the most recently
stored recurring detail.
•
recurring
o
contract
This should be the same value that was submitted using recurringContract in the payment where the recurring
contract was created. However, if “ONECLICK,RECURRING” was specified initially, then this field should be
“RECURRING”. Please refer to section 3 for more information.
•
merchantAccount
The merchant account for which you want to process the payment.
•
amount
The amount to authorise. This consists of a currencyCode and a paymentAmount. Please refer to section 2.2 of the Adyen
Merchant Integration Manual for more information.
•
shopperEmail
The shopper's email address. This does not have to match the email address supplied with the initial payment.
•
shopperReference
An ID that uniquely identifies the shopper. This shopperReference must be the same as the shopperReference used in the
initial payment.
•
shopperInteraction
Set to “ContAuth”.
11
5.2. Payment response
If the recurring payment message passes validation, a risk analysis will be done and, depending on the outcome, an authorisation will
be attempted. This is not applicable to One-Click payments. You receive a payment response with the following fields:
•
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”.
•
authCode
An authorisation code if the payment was successful. Blank otherwise.
•
refusalReason
Adyen's mapped refusal reason, if the payment was refused.
Please refer to Step 3 of Appendix B for a SOAP example of a Recurring payment request and response.
Please refer to Appendix D for a REST example of a Recurring payment request and response.
12
6. Updating stored details
The stored payment details may need to be updated, for example when the card expiry date changes. Submit the Recurring payment
and add the details that need to change to the payment method specific object. For a card this means that the expiryMonth and
expiryYear fields should contain the new values. You need to specify the exact selectedRecurringDetailReference of the card that you
want to update.
Please note:
•
•
•
Updating of stored details is only applicable to cards.
The details will only be updated If the payment is successful.
A new recurringDetailReference is created and the old one is no longer valid. As such the stored details must be retrieved
again for the next payment.
Please refer to Appendix E for a SOAP example of a Recurring Payment Request which overwrites the expiry date of the card.
Please refer to Appendix F for a REST example of a sRecurring Payment Request which overwrites the expiry date of the card.
13
7. Disabling a recurring contract
You can disable a single recurringDetail or the whole recurring contract for a shopper.
7.1. Disable request
Disabling a recurring contract (detail) can be done by calling the disable action on the Recurring service.
The request has the following fields:
•
merchantAccount
Your merchant account.
•
shopperReference
The ID that uniquely identifies the shopper. This shopperReference must be the same as the shopperReference used in the
initial payment.
•
recurringDetailReference (optional)
The recurringDetailReference of the detail you wish to disable. If you do not supply this field all details for the shopper will be
disabled including the contract. This means that you cannot add new details.
7.2. Disable response
The response will be a result object with a single field response. If a single detail was disabled the value of this field will be [detailsuccessfully-disabled] or, if all the details were disabled, the value is [all-details-successfully-disabled].
Please refer to Appendix G for a SOAP example of a disable a recurring contract request and response.
Please refer to Appendix H for a REST example of a disable a recurring contract request and response.
14
8. Supported payment methods
For most payment methods the recurring payment is processed using the same payment method as the initial payment. There are a
few exceptions that are outlined below.
Please note, it must be clear to your shoppers that their details are to be used for recurring payments. We recommend adding
verbiage to your website advising shoppers of this.
8.1. card
All credit and debit cards support recurring with the exception of maestro, these cards cannot be used for recurring payments.
st
8.2. directdebit_NL – to be deprecated 1 August 2014
With the introduction of SEPA Direct Debits (SDD), directdebit_NL will be deprecated and no longer supported.
st
8.3. elv – to be deprecated 1 August 2014
With the introduction of SEPA Direct Debits (SDD), elv will be deprecated and no longer supported.
8.4. directEbanking
directEbanking is a payment method that requires some form of shopper interaction, which is not possible for recurring payments.
As such, the initial payment is completed via directEbanking and the recurring payments are processed as elv and SEPA Direct Debit.
directEbanking, elv and SEPA Direct Debit must be enabled for your Merchant Account for processing recurring payments. If you do
not want to display elv or SEPA Direct Debit on your HPP, you will need to deactivate them in your skin.
In order to correctly process SEPA Direct Debit recurring payments, the recurring request must include the selectedBrand element
with a value of “sepadirectdebit”.
Please note, with the introduction of SEPA Direct Debits (SDD), elv will be deprecated and no longer supported. We recommend
implementing SDD as described in section 8.8.
8.5. giropay
Recurring is only supported when the shopper has used a German bank account.
giropay is a payment method that requires some form of shopper interaction, which is not possible for recurring payments. As such,
the initial payment is completed via giropay and the recurring payments are processed as elv.
giropay, elv, and SEPA Direct Debit must be enabled for your Merchant Account for processing recurring payments. If you do not
want to display elv on your HPP, you will need to deactivate it in your skin.
Please note, with the introduction of SEPA Direct Debits (SDD), elv will be deprecated and no longer supported. We recommend
implementing SDD as described in section 8.8.
8.6. iDEAL
Recurring via iDEAL is not enabled by default. Please contact the Adyen Support Team ([email protected]) if you would like to have
this enabled.
iDEAL is a payment method that requires some form of shopper interaction, which is not possible for recurring payments. As such,
the initial payment is completed via iDEAL and the recurring payments are processed as SEPA Direct Debit.
Both iDEAL and SEPA Direct Debit must be enabled for your Merchant Account for processing recurring payments. If you do not want
to display directdebit_NL on your HPP, you will need to deactivate it in your skin.
15
Please note, with the introduction of SEPA Direct Debits (SDD), directdebit_NL will be deprecated and no longer supported. We
recommend implementing SDD as described in section 8.8.
8.7. paypal
The recurring functionality has to be approved by PayPal and they will need to add the merchantInitiatedBilling / Reference
Transactions permission to your PayPal account.
Please note, PayPal places a limit on the transaction amount of subsequent payments.
8.8. SEPA Direct Debit
In order to be correctly processed, the recurring payment request must include the selectedBrand element with a value of
“sepadirectdebit”.
8.9. Neteller
8.10. Moneybookers/Skrill
8.11. Direct Debit Brazil
16
9. Account Updater
Visa and Mastercard offer merchants the ability to register for their Account Updater services; Adyen has developed additional
functionality to support this. The service allows you to receive updates on:
•
•
•
cards that have expired and a new expiry date is available.
cards that have been replaced by a new card.
cards that have been reported stolen or where the customer has informed their issuer that they no longer authorise a
merchant to automatically charge their card.
You will need to build the mechanism to request the updates that will be processed by Adyen.
9.1. Requesting updates on stored cards
There are two methods that you can use to submit a request to Adyen to initiate updates for specific card details:
1.
Single update via API request
The API update requests are submitted using the ScheduleAccountUpdater action.
Here is the process:
o
You will submit a SOAP call that includes either the recurringDetailReference for the stored card or the card object
with the card details populated.
o
Adyen will respond and confirm receipt of the request or a failure, the reason field will provide you with the
details of the failure. Such as, the card has already been submitted for an update during the past 7 days.
o
Adyen processes update requests once per day.
Please refer to Appendix I for a SOAP Account Updater API request and response using card data.
Please refer to Appendix J for a SOAP Account Updater API request and response using token data.
2.
Periodical update via a Batch file
Here is the process:
o
You will generate a CSV file that includes the recurringDetailReference for every stored card that needs to be
updated.
o
o
File is submitted via SFTP to Adyen.
Adyen will run validation checks on the file and will respond to confirm receipt and inform you if there were any
problems with the structure of the file.
o
Adyen processes update requests once per day.
Please refer to Appendix K for a sample Account Updater batch file.
On a daily basis Adyen submits the cards, for which an update has been requested, to the card schemes and typically receives
feedback, with the updated information, from the card schemes after two days.
For updates requested via the batch files, the result of the update is provided in a CSV response file. For API requests, the result of
the update is communicated via a notification with the eventCode “ACCOUNT_UPDATER_RESULT” and contains the relevant updated
details, the fields are as follows:
•
success
Whether or not the event succeeded (boolean true/false).
•
reason
For ACCOUNT_UPDATER_RESULT events with the success field set to true values include:
o
o
o
o
o
NoChange
CloseAccount
CloseAccountThisAccountOnly
CardChanged
CardExpiryChanged
When the success field is set to false it gives a reason as to why it failed.
17
The additionalData fields will be populated with the updated details according to the reason value. For example, where the reason is
CardExpiryChanged, the additionalData will be only populated with the updated expiry data, and where the reason is CardChanged,
the additionalData will be populated with the new alias and expiry data.
<additionalData>
<entry>
<key xsi:type="xsd:string">newExpiryMonth</key>
<value xsi:type="xsd:string">2</value>
</entry>
<entry>
<key xsi:type="xsd:string">newExpiryYear</key>
</entry>
<entry>
<key xsi:type="xsd:string">newAlias</key>
<value xsi:type="xsd:string">G184393236666944</value>
</entry>
</additionalData>
You may also use the listRecurringDetails call as an alternative for determining if there have been any updates.
For more information regarding Adyen's Batch Processing files, please refer to the Adyen Batch Manual.
9.2. Responses to update requests
Adyen maintains a central list with card data where the “lifecycle” of a card will be registered, this list serves as a reference for the
card data that is stored for recurring payments for merchants.
Adyen will perform a specific action depending upon the response back from the card schemes. The following scenarios can occur:
•
No update on card
o
There have not been any changes to the card details, the central list is not updated; Adyen registers the date of
the latest update check.
•
Expiry date update on card
o
Adyen will maintain version control on any updates. The old card data remain registered on the central list under
version 1; the system will add the new expiry date to the stored card on the central list and will register the date
of the change, the updated details will be stored with an incrementing version number.
o
o
Adyen does not change the recurringDetailReference that is stored.
When you next retrieve the recurring details for a shopper, via the listRecurringDetails action, Adyen will provide
you with the updated details registered for this card in the additionalData section of the response.
Please refer to Appendix M for a SOAP example of a List Recurring Details response with an updated expiry date.
Please refer to Appendix N for a REST example of a List Recurring Details response with an updated expiry date.
o
Adyen will continue to process recurring transactions using the old card data until you provide the updated
details in an authorisation request.
o
Once a payment has been successfully processed using the new expiry date, Adyen will automatically update the
recurringDetailReference with the new expiry date.
•
New card number issued for card
It is possible that the customer's card number has been updated. In this scenario the following process is applicable:
o
o
Adyen will generate a new Alias for this card.
Adyen will provide you with the new Alias via the notification for API driven requests, and via the result file for
batch driven requests. This may also be retrieved by calling the listRecurringDetails action.
o
The old card remains stored under the original Alias and recurringDetailReference, you can continue to use the old
card until it is declined.
o
The listRecurringDetails call returns all the enabled recurringDetailReferences. The updated details will be returned
in the additionalData until a payment is initiated using the updated details. We suggest that you disable the old
recurringDetailReferences so that only the relevant details are returned.
18
Please refer to Appendix O for a SOAP example of a List Recurring Details response with updated card information.
Please refer to Appendix P for a REST example of a List Recurring Details response with updated card information.
•
The detail is disabled
It is possible that the issuing bank requests that the stored details are invalidated, this may occur if the card has been
reported as stolen or if the customer called the bank and informed them that they no longer authorise transactions from a
specific merchant. In this scenario the following process is applicable:
o
o
Adyen will disable the recurringDetailReference.
Adyen will provide you with the update via the notification system for API driven requests, and via the result file
for batch driven requests. The detail will no longer be displayed when calling listRecurringDetails.
Please note, the contract is not disabled.
Please note, in order to receive the changed details back via the additionalData fields, you must use version 6 of the Adyen
Recurring service. Please refer to Appendix A for the URLs.
9.3. Using the updated details
Adyen will not automatically update your stored tokens to use the new details; you will need to submit an authorise request for the
update to occur.
•
Expiry date update on card
o
You will submit an authorise request as described in section 5; you will include the card container with all the
fields set to null except for the updated expiry date fields, except for One-Click payments for which you will also
provide the cvc value.
Please refer to Appendix Q for a SOAP example of a payment request using the updated expiry date.
Please refer to Appendix R for a REST example of a payment request using the updated expiry date.
•
New card number issued for card
o
You will submit an authorise request as described in section 5; you will include the card container with all the
fields populated with the updated values. The card field should be populated with the new card Alias; the
shopperInteraction should be set to 'ContAuth'.
Please refer to Appendix S for a SOAP example of a payment request using the updated card information.
Please refer to Appendix T for a REST example of a payment request using the updated card information.
19
10. FAQ
1. What does response '107 – Recurring is not enabled' mean?
Recurring is not enabled by default. Please contact the Adyen Support Team ([email protected]) to have recurring activated for
your account. Please specify your Company Account in your request.
2. What does response '905 Payment details are not supported' mean?
You receive this error if you try to submit a recurring payment where the payment method or currency are not available. For
example, if you attempt a USD payment when only EUR is enabled on your merchant account. To check the payment methods for
your merchant account in the CA, navigate to “Settings” → “Payment Methods”.
3. What does response 'The server sent HTTP status code 401: Unauthorized' mean?
Your webservice was not able to login properly. Verify that you are using:
•
•
•
The correct Service URL (Payment or Recurring).
The correct username.
The configured password.
4. Is it possible to setup a recurring contract without a payment?
This is possible in one of three ways:
1.
Tokenisation. This method assumes your own systems have already stored authorised credit card details. Please discuss
this option further with your account manager.
2.
Dynamic Zero Value Auth. For card transactions, 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 verification
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 verification, 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.
3.
The following workaround:
a.
In the Adyen CA, ensure the Capture Delay is not set to "immediate" in “Settings” → “Merchant Settings”.
b.
Create an initial payment for a small amount, such as EUR1,00 and set the recurringContract field to "RECURRING"
or "ONECLICK,RECURRING".
c.
Check that the payment is authorised.
d.
Cancel the authorisation before the capture delay time period is met, if any.
The outcome is as follows:
•
•
•
Full authorisation takes place on the card, including CVC checks, 3D secure authentication, if applicable.
If cancellation occurs before the capture, the shopper is not charged.
The card details are stored/tokenised in Adyen.
The shopper should be warned that a small authorisation will take place on their card if using this workaround.
20
Appendix A: TEST and LIVE URLs
Test URL’s
Hosted Payment Pages (Multiple):
https://test.adyen.com/hpp/select.shtml
Hosted Payment Pages (Single):
https://test.adyen.com/hpp/pay.shtml
SOAP Payment Service
https://pal-test.adyen.com/pal/servlet/soap/Payment
SOAP Payment Service WSDL
https://pal-test.adyen.com/pal/Payment.wsdl
HTTP Adapter (Browser)
https://pal-test.adyen.com/pal/adapter/httppost?Payment
SOAP Recurring Service v6
https://pal-test.adyen.com/pal/servlet/soap/Recurring/V6
REST Recurring Service v6
https://pal-test.adyen.com/pal/servlet/Recurring/listRecurringDetails/V6
Live URL’s
Hosted Payment Pages (Multiple):
https://live.adyen.com/hpp/select.shtml
Hosted Payment Pages (Single):
https://live.adyen.com/hpp/pay.shtml
SOAP Payment Service
https://pal-live.adyen.com/pal/servlet/soap/Payment
SOAP Payment Service WSDL
https://pal-live.adyen.com/pal/Payment.wsdl
HTTP Adapter (Browser)
https://pal-live.adyen.com/pal/adapter/httppost?Payment
SOAP Recurring Service v6
https://pal-live.adyen.com/pal/servlet/soap/Recurring/V6
REST Recurring Service v6
https://pal-live.adyen.com/pal/servlet/Recurring/listRecurringDetails/V6
21
Appendix B: Complete workflow example
To help understand the principles outlined in this manual, we will walk through a scenario, from the initial payment through to
subsequent recurring payments.
The Merchant has two offerings – products and subscriptions. For products, the shopper selects a product, pays, and then has the
item delivered to them. The Merchant has decided that, for certain products, they will allow the shopper to choose from an existing
stored card, if it exists, or the option to add a new one.
For subscriptions, the shopper selects a service, pays upfront for the first month, with the option to select from existing stored cards
if they exist, and agrees to be automatically charged every month until they cancel. The Merchant has decided that, for subscriptions
only, they will always use the last stored card details for the shopper in subsequent months.
Step 1: First initial recurring payment
st
On the 1 of January 2014 a shopper signs up with the Merchant and is making their first purchase of a product.
The Merchant creates a Payment request including the required additional fields as follows:
•
•
•
shopperReference: grasshopper77
shopperEmail: [email protected]
recurringContract: RECURRING
The payment request might look as follows:
<input type="hidden" name="merchantReference" value="ProductOrder041-201" />
<input type="hidden" name="paymentAmount" value="5000" />
<input type="hidden" name="currencyCode" value="EUR" />
<input type="hidden" name="shipBeforeDate" value="2014-02-01" />
<input type="hidden" name="skinCode" value="4aD37dJA" />
<input type="hidden" name="merchantAccount" value="SupportAdyenDemo" />
<input type="hidden" name="shopperLocale" value="en_GB" />
<input type="hidden" name="orderData"
value="H4sIAAAAAAAAALMpsOPlCkssyswvLVZIz89PKVZIzEtRKE4tKstMTi3W4+Wy0S+wAwDOGUCXJgAAAA==" />
<input type="hidden" name="sessionValidity" value="2014-01-02T11:00:00Z" />
<input type="hidden" name="merchantSig" value="33syARtfsxD47jeXzOlEyZ0j3pg=" />
<input type="hidden" name="recurringContract" value="RECURRING" />
Once on the HPP, the shopper successfully uses a Visa card ending 1111, and the Merchant receives an AUTHORISATION notification
of successful payment. The merchant now knows the recurring detail has been stored, with a new recurring contract created. The
Merchant does not receive any information about the recurring details, as these are not needed at this point.
Step 2: listRecurringDetails for a shopper
th
A week later, on 8 January 2014, the same shopper returns to the website and purchases a subscription.
The Merchant decides to check to see if the shopper has any stored recurring details:
<?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/XMLSchema-instance">
<soap:Body>
<ns1:listRecurringDetails xmlns:ns1="http://recurring.services.adyen.com">
<ns1:request>
<ns1:recurring>
<contract xmlns="http://payment.services.adyen.com">RECURRING</value>
22
</ns1:recurring>
<ns1:merchantAccount>SupportAdyenTest</ns1:merchantAccount>
<ns1:shopperReference>grasshopper77</ns1:shopperReference>
</ns1:request>
</ns1:listRecurringDetails>
</soap:Body>
</soap:Envelope>
The response comes back that there is one stored card for the shopper – the Visa from the first payment. Here we can see the
recurringDetailReference for the first time:
<soap:Body>
<ns1:listRecurringDetailsResponse xmlns:ns1="http://recurring.services.adyen.com">
<ns1:result>
<creationDate xmlns="http://recurring.services.adyen.com">2014-01-01T01:50:12.178+01:00</creationDate>
<details xmlns="http://recurring.services.adyen.com">
<RecurringDetail>
<bank xsi:nil="true"/>
<card>
<cvc xmlns="http://payment.services.adyen.com" xsi:nil="true"/>
<expiryMonth xmlns="http://payment.services.adyen.com">12</expiryMonth>
<expiryYear xmlns="http://payment.services.adyen.com">2016</expiryYear>
<holderName xmlns="http://payment.services.adyen.com">Grass Hopper</holderName>
<number xmlns="http://payment.services.adyen.com">1111</number>
</card>
<creationDate>2014-01-01T01:50:16.353+01:00</creationDate>
<elv xsi:nil="true"/>
<name xsi:nil="true"/>
<recurringDetailReference>8313147988756818</recurringDetailReference>
<variant>visa</variant>
</RecurringDetail>
</details>
<lastKnownShopperEmail
xmlns="http://recurring.services.adyen.com">[email protected]</lastKnownShopperEmail>
<shopperReference xmlns="http://recurring.services.adyen.com">grashopper77</shopperReference>
</ns1:result>
</ns1:listRecurringDetailsResponse>
</soap:Body>
</soap:Envelope>
Step 3: Subsequent payment
Based upon the results of step 2, the Merchant offers the shopper the choice of using the previously stored card ending with “1111”
or a new card. The shopper chooses to use the existing card ending with “1111”, so the Merchant can now submit a Payment without
the shopper needing to enter their card details again.
The merchant submits a Payment request with the following additional fields:
•
•
•
selectedRecurringDetailReference: In this case it is “8313147988756818”
recurring / contract: “RECURRING” since it was set this way in Step 1
shopperInteraction: “ContAuth” since the contract is RECURRING
The payment request, this time sent via SOAP, might look as follows:
23
<soap:Body>
<ns1:authorise xmlns:ns1="http://payment.services.adyen.com">
<ns1:paymentRequest>
<amount xmlns="http://payment.services.adyen.com">
<currency xmlns="http://common.services.adyen.com">EUR</value>
<value xmlns="http://common.services.adyen.com">4000</value>
</amount>
<ns1:reference>SubscriptionOrder031-241</ns1:reference>
<ns1:shopperEmail>[email protected]</ns1:shopperEmail>
<ns1:selectedRecurringDetailReference>8313147988756818</ns1:selectedRecurringDetailReference>
<ns1:recurring>
<ns1:contract>RECURRING</ns1:contract>
</ns1:recurring>
<ns1:shopperInteraction>ContAuth</ns1:shopperInteraction>
</ns1:paymentRequest>
</ns1:authorise>
</soap:Body>
</soap:Envelope>
The response might look as follows:
<soap:Body>
<ns1:authoriseResponse xmlns:ns1="http://payment.services.adyen.com">
<ns1:paymentResult>
<authCode xmlns="http://payment.services.adyen.com">64158</authCode>
<pspReference xmlns="http://payment.services.adyen.com">8613147994700690</pspReference>
<resultCode xmlns="http://payment.services.adyen.com">Authorised</resultCode>
</ns1:paymentResult>
</ns1:authoriseResponse>
</soap:Body>
</soap:Envelope>
Notifications are also sent, as was the case in Step 1.
Step 4: Storing a second recurring detail
On 17 January 2014, the shopper purchases another product from the Merchant.
As with Step 2, the Merchant retrieves a list of the stored recurring details and gets the same result as presented there. The
Merchant offers the shopper the choice of using the previously stored card ending with “1111” or a new card. This time the shopper
chooses to use a new card, so the Merchant must now submit a Payment where they will create another recurring detail on an
existing recurring contract.
The payment request might look as follows:
<input type="hidden" name="merchantReference" value="ProductOrder053-204" />
<input type="hidden" name="paymentAmount" value="3133" />
<input type="hidden" name="currencyCode" value="EUR" />
<input type="hidden" name="shipBeforeDate" value="2014-01-17" />
<input type="hidden" name="skinCode" value="4aD37dJA" />
<input type="hidden" name="merchantAccount" value="SupportAdyenTest" />
<input type="hidden" name="shopperLocale" value="en_GB" />
24
<input type="hidden" name="orderData"
value="H4sIAAAAAAAAALMpsOPlCkssyswvLVZIz89PKVZIzEtRKE4tKstMTi3W4+Wy0S+wAwDOGUCXJgAAAA==" />
<input type="hidden" name="sessionValidity" value="2014-01-18T11:00:00Z" />
<input type="hidden" name="merchantSig" value="33syWRtfDxDwq3235zOlEyZ0j3pg=" />
<input type="hidden" name="recurringContract" value="RECURRING" />
Once on the HPP, the shopper successfully uses a Mastercard ending 4444, and the Merchant receives an AUTHORISATION
notification of successful payment. The merchant now knows the recurring detail has been stored against the existing recurring
contract. The Merchant does not receive any information about the recurring details, as these are not needed at this point.
There is now one recurring contract with two recurring details – the Visa card from the first purchase, and the Mastercard from this
purchase.
Step 5: Second subsequent payment
On 08 February 2014, a month has passed and the Merchant now needs to charge the shopper the next installment of their
subscription. Since the Merchant has chosen to use the latest stored details of the shopper they do not need to go through Step 2.
Instead they can immediately submit the Payment request with the following additional fields:
•
•
•
selectedRecurringDetailReference: “LATEST”
recurring / contract: “RECURRING” since it was set this way in Step 1
shopperInteraction: “ContAuth” since the contract is RECURRING
The payment request, this time sent via SOAP, might look as follows:
<soap:Body>
<currency xmlns="http://common.services.adyen.com">EUR</currency>
</amount>
<ns1:selectedRecurringDetailReference>LATEST</ns1:selectedRecurringDetailReference>
<ns1:recurring>
</ns1:recurring>
</ns1:authorise>
</soap:Body>
</soap:Envelope>
The response is similar to that of Step 3, except that the Mastercard from Step 4 is used for the Payment, and not the Visa card from
Steps 1 & 3, since it was the most recently used recurring detail for this shopper.
This can be verified by looking up the recurring details for the shopper and noting the creationDate in each RecurringDetail:
25
<soap:Body>
<ns1:result>
<creationDate xmlns="http://recurring.services.adyen.com">2014-01-01T01:50:12.178+01:00</creationDate>
<RecurringDetail>
<card>
</card>
<variant>mc</variant>
</RecurringDetail>
<RecurringDetail>
<card>
</card>
<variant>visa</variant>
</RecurringDetail>
</details>
</ns1:result>
</soap:Body>
</soap:Envelope>
The above listRecurringDetails Response has been truncated to remove some lines with nil results.
26
Appendix C: REST example of a listRecurringDetails request and
response
Request
action=Recurring.listRecurringDetails
&recurringDetailsRequest.merchantAccount=SupportAdyenTest&recurringDetailsRequest.shopperReference=grasshopper&
recurringDetailsRequest.recurring.contract=RECURRING
Response
recurringDetailsResult.creationDate=2014-01-01T15%3A02%3A08%2B01%3A00&
recurringDetailsResult.details.0.card.expiryMonth=6& recurringDetailsResult.details.0.card.expiryYear=2016&
recurringDetailsResult.details.0.card.holderName=test& recurringDetailsResult.details.0.card.number=1111&
recurringDetailsResult.details.0.creationDate=2014-01-22T15%3A02%3A08%2B01%3A00&
recurringDetailsResult.details.0.recurringDetailReference=8413903993289958& recurringDetailsResult.details.0.variant=visa&
recurringDetailsResult.details.1.card.expiryMonth=6& recurringDetailsResult.details.1.card.expiryYear=2016&
recurringDetailsResult.details.1.card.holderName=Consumer& recurringDetailsResult.details.1.card.number=1111&
recurringDetailsResult.details.1.recurringDetailReference=8313905562367504& recurringDetailsResult.details.1.variant=mc&
recurringDetailsResult.lastKnownShopperEmail=test%40shopper.nl& recurringDetailsResult.shopperReference=SHOPPER1
27
Appendix D: REST example of a recurring payment request and
response
Request
action=Payment.authorise
&paymentRequest.amount.currency=EUR&paymentRequest.amount.value=1234&paymentRequest.merchantAccount=
SupportAdyenTest&paymentRequest.reference=test1234&paymentRequest.shopperReference=gras.shopper77&
[email protected]&paymentRequest.shopperIP=1.1.1.1&
paymentRequest.selectedRecurringDetailReference=RecurringDetailReference1&
paymentRequest.recurring.contract=RECURRING&shopperInteraction=ContAuth
Response
paymentResult.authCode=64158&paymentResult.pspReference=8613147994700690&paymentResult.resultCode=Authorised
28
Appendix E: SOAP example for updating stored details
Request
<soap:Body>
</amount>
<ns1:card>
<ns1:expiryMonth>11</ns1:expiryMonth>
<ns1:expiryYear>2016</ns1:expiryYear>
</ns1:card>
<ns1:reference>RecurringPayment-0001</ns1:reference>
<ns1:shopperIP>1.1.1.1</ns1:shopperIP>
<ns1:selectedRecurringDetailReference>RecurringDetailReference1</ns1:selectedRecurringDetailReference>
<ns1:recurring>
</ns1:recurring>
</ns1:authorise>
</soap:Body>
</soap:Envelope>
Response
<soap:Body>
<ns1:authoriseResponse xmlns:ns1="http://payment.services.adyen.com">
<ns1:paymentResult>
<authCode xmlns="http://payment.services.adyen.com">79688</authCode>
<pspReference xmlns="http://payment.services.adyen.com">8613904894998224</pspReference>
<resultCode xmlns="http://payment.services.adyen.com">Authorised</resultCode>
</ns1:paymentResult>
</ns1:authoriseResponse>
</soap:Body>
</soap:Envelope>
Please note, the response to this request is a regular authorise payment response.
29
Appendix F: REST example for updating stored details
Request
&paymentRequest.amount.currency=EUR&paymentRequest.amount.value=1234&
paymentRequest.card.expiryMonth=06&paymentRequest.card.expiryYear=2016&paymentRequest.merchantAccount=
SupportAdyenTest&paymentRequest.reference=test1234&paymentRequest.shopperReference=gras.shopper77&
[email protected]&paymentRequest.shopperIP=1.1.1.1&
paymentRequest.selectedRecurringDetailReference=RecurringDetailReference1&paymentRequest.recurring.contract=RECURRING
&paymentRequest.shopperInteraction=ContAuth
Response
Please note, the response to this request is a regular authorise payment response.
30
Appendix G: SOAP example of a disable recurring contract request and
response
Request
<soap:Body>
<ns1:disable xmlns:ns1="http://recurring.services.adyen.com">
<ns1:request>
<ns1:recurringDetailReference>8313147988756818</ns1:recurringDetailReference>
</ns1:request>
</ns1:disable>
</soap:Body>
</soap:Envelope>
Response
<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/XMLSchema-instance">
<soap:Body>
<ns1:disableResponse xmlns:ns1="http://recurring.services.adyen.com">
<ns1:result>
<response xmlns="http://recurring.services.adyen.com">[detail-successfully-disabled]</response>
</ns1:result>
</ns1:disableResponse>
</soap:Body>
</soap:Envelope>
31
Appendix H: REST example of a disable recurring contract request and
response
Request
action=Recurring.disable
&disableRequest.merchantAccount=SupportAdyenTest&disableRequest.shopperReference=grasshopper77&disableRequest.
recurringDetailReference=8313147988756818
Response
disableResult.response=%5Bdetail-successfully-disabled%5D
32
Appendix I: SOAP account updater request and response using card
data
Request
<?xml version="1.0" encoding="UTF-8"?>
<soap:Body>
<ns1:scheduleAccountUpdater xmlns:ns1="http://recurring.services.adyen.com">
<ns1:request>
<merchantAccount xmlns:ns1="http://recurring.services.adyen.com">SupportAdyenTest</merchantAccount>
<reference>Your Reference Here</reference>
<card xmlns="http://payment.services.adyen.com">
<expiryMonth xmlns:ns1="http://payment.services.adyen.com">12</expiryMonth>
<expiryYear xmlns:ns1="http://payment.services.adyen.com">2012</expiryYear>
<holderName xmlns:ns1="http://payment.services.adyen.com">Adyen Test</holderName>
<number xmlns:ns1="http://payment.services.adyen.com">4111111111111111</number>
</card>
</ns1:request>
</ns1:scheduleAccountUpdater>
</soap:Body>
</soap:Envelope>
Response
<soap:Body>
<ns1:scheduleAccountUpdaterResponse xmlns:ns1="http://recurring.services.adyen.com">
<ns1:result>
<pspReference xmlns="http://recurring.services.adyen.com">8313547924770610</pspReference>
<result xmlns="http://recurring.services.adyen.com">Success</result>
</ns1:result>
</ns1:scheduleAccountUpdaterResponse>
</soap:Body>
</soap:Envelope>
33
Appendix J: SOAP account updater request and response using token
data
Request
<soap:Body>
<ns1:scheduleAccountUpdater xmlns:ns1="http://recurring.services.adyen.com">
<ns1:request>
<merchantAccount xmlns:ns1="http://recurring.services.adyen.com">SupportAdyenTest</merchantAccount>
<reference xmlns:ns1="http://recurring.services.adyen.com">Your Reference Here</reference>
<shopperReference xmlns:ns1="http://recurring.services.adyen.com">The Shopper Reference</shopperReference>
<selectedRecurringDetailReference
xmlns:ns1="http://recurring.services.adyen.com">TheSelectedRecurringDetailReference</selectedRecurringDetailReference>
</ns1:request>
</ns1:scheduleAccountUpdater>
</soap:Body>
</soap:Envelope>
Response
<soap:Body>
<ns1:scheduleAccountUpdaterResponse xmlns:ns1="http://recurring.services.adyen.com">
<ns1:result>
<result xmlns="http://recurring.services.adyen.com">Success</result>
</ns1:result>
</ns1:scheduleAccountUpdaterResponse>
</soap:Body>
</soap:Envelope>
34
Appendix K: Sample Account Updater batch file
Request
FH,1.0,TEST,Company,SupportAdyen,Default,1,[email protected],AccountUpdater,FileHeaderEchoData
BH,1,BlockHeaderEchoData
L,1,MerchantAccount,SupportAdyenTest,AccountUpdater,MerchantReference,EchoData
SL,1,AccountUpdaterRecurring,ShopperRef012A,8104963078926481
L,2,MerchantAccount,SupportAdyenTest,AccountUpdater,MerchantReference1,EchoData1
SL,1,AccountUpdaterRecurring,ShopperRef345A,8193468172596018
SL,1,AccountUpdaterRecurring,ShopperRef678A,LATEST
SL,1,AccountUpdaterRecurring,ShopperRef901B,8192487112598013
BT,6
FT,1
Response
FH,1.0,TEST,Company,SupportAdyen,Default,1,[email protected],AccountUpdater,FileHeaderEchoData
BH,1,BlockHeaderEchoData
L,1,MerchantAccount,SupportAdyen,AccountUpdater,Success,9874560210158742,EchoData
SL,1,AccountUpdaterResult,9874560210158742,Submitted,NoChange,2013-11-13,,,
L,2,MerchantAccount,SupportAdyen,AccountUpdater,Success,9874560210158786,
SL,1,AccountUpdaterResult,9874560210158786,Submitted,CloseAccount,2013-11-13,,,
SL,1,AccountUpdaterResult,9458762458135487,Submitted,PANChanged,2013-11-13,D123456789,07,2018
SL,1,AccountUpdaterResult,9584215412154876,Submitted,CardExpiryChanged,2013-09-15,,03,2017
SL,1,AccountUpdaterResult,9248414112548965,Submitted,Error,2013-09-15,,,
SL,1,AccountUpdaterResult,9815487887958742,Not Submitted,,,,,,No registered account
BT,6
FT,1
35
Appendix L: SOAP tokenLookup request and response
Request
<soap:Body>
<ns1:tokenLookup xmlns:ns1="http://recurring.services.adyen.com">
<ns1:request>
<merchantAccount xmlns="http://recurring.services.adyen.com">SupportAdyenTest</merchantAccount>
<card xmlns:ns1="http://recurring.services.adyen.com">
<holderName xmlns="http://payment.services.adyen.com">T. Est</holderName>
</card>
</ns1:request>
</ns1:tokenLookup>
</soap:Body>
</soap:Envelope>
Response
<soap:Body>
<ns1:tokenLookupResponse xmlns:ns1="http://recurring.services.adyen.com">
<ns1:result>
<additionalData xmlns="http://recurring.services.adyen.com" xsi:nil="true"/>
<tokens xmlns="http://recurring.services.adyen.com">
<tokenDetail>
<creationDate>2013-09-12T10:13:09+02:00</creationDate>
<lastKnownShopperEmail>[email protected]</lastKnownShopperEmail>
<shopperReference>shopperReference001</shopperReference>
</tokenDetail>
<tokenDetail>
</tokenDetail>
<tokenDetail>
</tokenDetail>
</tokens>
</ns1:result>
</ns1:tokenLookupResponse>
</soap:Body>
</soap:Envelope>
36
Appendix M: SOAP listRecurringDetails response with updated expiry
date
<soap:Body>
<ns1:result>
<creationDate xmlns="http://recurring.services.adyen.com">2012-12-03T17:43:42+01:00</creationDate>
<RecurringDetail>
<additionalData>
<entry>
<key xsi:type="xsd:string">cardBin</key>
</entry>
<entry>
</entry>
<entry>
</entry>
<entry>
<key xsi:type="xsd:string">lastAccountUpdaterCheck</key>
<value xsi:type="xsd:string">2014-03-22 10:01:11.883+01</value>
</entry>
</additionalData>
<alias>M104640077590143</alias>
<aliasType>Default</aliasType>
<card>
</card>
<tokenDetails>
<tokenData xmlns="http://payment.services.adyen.com" xsi:nil="true" />
<tokenDataType xmlns="http://payment.services.adyen.com" xsi:nil="true" />
</tokenDetails>
</RecurringDetail>
</details>
</ns1:result>
</soap:Body>
</soap:Envelope>
37
Appendix N: REST listRecurringDetails response with updated expiry
date
recurringDetailsResult.details.0.card.expiryMonth=6&
recurringDetailsResult.details.0.card.expiryYear=2016&
recurringDetailsResult.details.0.card.holderName=test&
recurringDetailsResult.details.0.card.number=1111&
recurringDetailsResult.details.0.recurringDetailReference=8413903993289958&
recurringDetailsResult.details.0.variant=visa&
recurringDetailsResult.details.1.card.holderName=Consumer&
recurringDetailsResult.details.1.variant=mc&
recurringDetailsResult.lastKnownShopperEmail=test%40shopper.nl&
recurringDetailsResult.shopperReference=SHOPPER1&
recurringDetailsResult.additionalData.newExpiryMonth=9&
recurringDetailsResult.additionalData.newExpiryYear=2016&
recurringDetailsResult.additionalData.lastAccountUpdaterCheck=2014-03-22 10:01:11.883+01
38
Appendix O: SOAP listRecurringDetails response with updated card
information
<soap:Body>
<ns1:result>
<RecurringDetail>
<additionalData>
<entry>
<key xsi:type="xsd:string">newAlias</key>
<value xsi:type="xsd:string">M104640658147143</value>
</entry>
<entry>
</entry>
<entry>
</entry>
<entry>
<key xsi:type="xsd:string">lastAccountUpdaterCheck</key>
<value xsi:type="xsd:string">2014-03-22 10:01:11.883+01</value>
</entry>
<entry>
<key xsi:type="xsd:string">newCardBin</key>
</entry>
<entry>
<key xsi:type="xsd:string">newCardSummary</key>
</entry>
</additionalData>
<alias>M104640077590143</alias>
<aliasType>Default</aliasType>
<card>
</card>
<tokenDetails>
<tokenData xmlns="http://payment.services.adyen.com" xsi:nil="true" />
<tokenDataType xmlns="http://payment.services.adyen.com" xsi:nil="true" />
</tokenDetails>
</RecurringDetail>
</details>
<shopperReference>grashopper77</shopperReference>
</ns1:result>
</soap:Body>
</soap:Envelope>
39
Appendix P: REST listRecurringDetails response with updated card
information
recurringDetailsResult.details.0.card.holderName=test&
recurringDetailsResult.details.0.variant=visa&
recurringDetailsResult.details.1.card.holderName=Consumer&
recurringDetailsResult.details.1.variant=mc&
recurringDetailsResult.lastKnownShopperEmail=test%40shopper.nl&
recurringDetailsResult.shopperReference=SHOPPER1&
recurringDetailsResult.additionalData.newAlias=M104640658147143&
recurringDetailsResult.additionalData.newExpiryMonth=9&
recurringDetailsResult.additionalData.newExpiryYear=2016&
recurringDetailsResult.additionalData.lastAccountUpdaterCheck=2014-03-22 10:01:11.883+01&
recurringDetailsResult.additionalData.newCardBin=555543&
recurringDetailsResult.additionalData.newCardSummary=1234
40
Appendix Q: SOAP payment request with updated expiry date
<soap:Body>
<expiryMonth>06</expiryMonth>
<expiryYear>2016</expiryYear>
<holderName></holderName>
<number></number>
<cvc></cvc>
</card>
</amount>
<ns1:recurring>
</ns1:recurring>
</ns1:authorise>
</soap:Body>
</soap:Envelope>
41
Appendix R: REST payment request with updated expiry date
Request
&paymentRequest.amount.currency=EUR&paymentRequest.amount.value=1234&paymentRequest.card.cvc=&paymentRequest.
card.expiryMonth=06&paymentRequest.card.expiryYear=2016&paymentRequest.card.holderName=&paymentRequest.card.
number=&paymentRequest.merchantAccount=SupportAdyenTest&paymentRequest.reference=test1234&paymentRequest.
selectedRecurringDetailReference=LATEST&paymentRequest.recurring.contract=RECURRING&shopperInteraction=ContAuth
Response
42
Appendix S: SOAP payment request with new card details
<soap:Body>
<expiryMonth>06</expiryMonth>
<expiryYear>2016</expiryYear>
<holderName>Adyen Test</holderName>
<number>AliasHere</number>
<cvc></cvc>
</card>
</amount>
<ns1:recurring>
</ns1:recurring>
</ns1:authorise>
</soap:Body>
</soap:Envelope>
43
Appendix T: REST payment request with new card details
Request
&paymentRequest.amount.currency=EUR&paymentRequest.amount.value=1234&paymentRequest.card.cvc=&paymentRequest.
card.expiryMonth=06&paymentRequest.card.expiryYear=2016&paymentRequest.card.holderName=Adyen+Test&
paymentRequest.card.number=AliasHere&paymentRequest.merchantAccount=SupportAdyenTest&paymentRequest.
reference=test1234&paymentRequest.selectedRecurringDetailReference=LATEST&paymentRequest.recurring.contract=
RECURRING&shopperInteraction=ContAuth
Response
44

Recurring payments manual Copyright (c) Adyen B.V. 2014

Transcription

Similar documents

JV Pitch Formula 1. Your name

Updated* Needs List

Investors Presentation

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

Who is Arvig?

THE SCOOP BEHIND

SES Bill Pay Portal Instructions

Ask About Our $10.00 Mufflers

RECURRING DECIMALS INTO FRACTIONS Edexcel GCSE