Welcome to Clearhaus Transaction API. You can use our API to process payment card transactions. The API is organized around REST and designed to have predictable and resource-oriented URLs. The table below basically sums up what you can do:
POST https://gateway.clearhaus.com/authorizations
POST https://gateway.clearhaus.com/authorizations/:id/captures
POST https://gateway.clearhaus.com/authorizations/:id/refunds
POST https://gateway.clearhaus.com/credits
To use this transaction API you must be a technical partner (and such partners must be PCI DSS L1).
API keys come with many privileges so keep them secret.
https://gateway.clearhaus.com # live accounts
https://gateway.test.clearhaus.com # test accounts
Authentication is done via HTTP Basic Auth. Simply provide your API key as
username and a blank string as password. Remember a colon :
after username
when using cURL to specify an empty password.
curl https://gateway.test.clearhaus.com \
-u <your-api-key>:
You will get this response when you provide an invalid API key:
HTTP/1.1 401 Not Authorized
The API follows HATEOAS principle of REST which means all resources are discoverable.
curl https://gateway.test.clearhaus.com \
-u <your-api-key>:
{
"_links": {
"authorizations": { "href": "/authorizations" },
"account": { "href": "/account" }
}
}
All responses will be delivered in JSON format (see JSON-HAL).
Content-Type: application/vnd.clearhaus-gateway.hal+json; version=0.10.0; charset=utf-8
where the version follows Semantic Versioning.
We use HTTP response codes to indicate API response status:
Number Text
200 OK
201 Created
400 Bad Request
401 Unauthorized
404 Not Found
5xx Server Error
There are two types of accounts:
Merchant accounts can process transactions whereas partner accounts cannot.
An API key (UUIDv4) points to an account (either a merchant account or a partner account). An account can have multiple API keys pointing to it; this allows for easy rolling of API keys. A merchant account usually uses one API key.
API keys can have an expire date. API keys can be enabled or disabled. For merchant accounts, these details can be observed in the Clearhaus Dashboard.
A partner account API key can be a signing API key, meaning that it has a verification key for verifying request signatures. This verification key is the public part of an RSA key pair; the RSA key pair is generated by the partner. The public part, the verification key, is communicated to Clearhaus during the technical integration.
Only partner accounts have signing API keys.
POST requests must be signed. Other requests can optionally be signed.
The signature is an RSA signature of the HTTP body; it is represented in hex.
The partner account is identified by the partner’s signing API key.
Both the partner’s signing API key and the RSA signature must be provided in a
Signature
header together with RS256-hex
:
Signature: <partner-signing-api-key> RS256-hex <signature>
Notice: If the signature header is included, it must hold a correct signature, otherwise the transaction will fail.
The RSA signature is an RSASSA-PKCS1-v1_5
signature of the body. It is
represented in hex.
If the signing API key is 0a1b2c3d-4e5f-4c2f-9999-000000000000
, the signing
private key (in PEM format) is
-----BEGIN RSA PRIVATE KEY-----
MIIBOwIBAAJBALYK0zmwuYkH3YWcFNLLddx5cwDxEY7Gi1xITuQqRrU4yD3uSw+J
WYKknb4Tbndb6iEHY+e6gIGD+49TojnNeIUCAwEAAQJARyuYRRe4kcBHdPL+mSL+
Y0IAGkAlUyKAXYXPghidKD/v/oLrFaZWALGM2clv6UoYYpPnInSgbcud4sTcfeUm
QQIhAN2JZ2qv0WGcbIopBpwpQ5jDxMGVkmkVVUEWWABGF8+pAiEA0lySxTELZm8b
Gx9UEDRghN+Qv/OuIKFldu1Ba4f8W30CIQCaQFIBtunTTVdF28r+cLzgYW9eWwbW
pEP4TdZ4WlW6AQIhAMDCTUdeUpjxlH/87BXROORozAXocBW8bvJUI486U5ctAiAd
InviQqJd1KTGRDmWIGrE5YACVmW2JSszD9t5VKxkAA==
-----END RSA PRIVATE KEY-----
and the body is
amount=2050¤cy=EUR&ip=1.1.1.1&card[pan]=4111111111111111&card[expire_month]=06&card[expire_year]=2022&card[csc]=123
then the Signature
header should be
Signature: 0a1b2c3d-4e5f-4c2f-9999-000000000000 RS256-hex 7ae0e14d35b2a15a7ff812a1899d7f0a5d28063f0c276081876a51fc3773f499459f944f8b57c6e0e76b47c218b20ebaad7c6250dcd1804dd19c87fb7f1216ba
In Ruby, you can calculate the RS256 hex signature using
key = OpenSSL::PKey::RSA.new(key_in_pem_string)
key.sign(OpenSSL::Digest.new('sha256'), body).unpack('H*').first
To charge a cardholder you first have to reserve money on his bank account. Next you can transfer money from his bank account to your merchant bank account.
The following will reserve EUR 20.50 (2050 cents) on cardholder’s bank account:
curl -X POST https://gateway.test.clearhaus.com/authorizations \
-u <your-api-key>: \
-d "amount=2050" \
-d "currency=EUR" \
-d "ip=1.1.1.1" \
-d "card[pan]=4111111111111111" \
-d "card[expire_month]=06" \
-d "card[expire_year]=2022" \
-d "card[csc]=123" \
-H "Signature: <signing-api-key> RS256-hex <signature>"
Example response (snippet):
{
"id": "84412a34-fa29-4369-a098-0165a80e8fda",
"status": {
"code": 20000
},
"csc": {
"present": true,
"matches": true
},
"processed_at": "2018-07-09T12:58:56+00:00",
"_links": {
"captures": { "href": "/authorizations/84412a34-fa29-4369-a098-0165a80e8fda/captures" }
}
}
In order to actually transfer money from cardholder’s bank account to your merchant bank account you will have to make a capture transaction.
Notice: Some issuers will approve authorizations although the CSC did not
match; in this case the status
code
will be
20000
but csc
matches
will be
false
. Please be aware that rules to disallow captures for such
authorizations may be in place for a merchant.
Notice: csc
matches
is true
if
issuer or card scheme confirmed CSC to match; it is false
if issuer
or card scheme did not perform validation or if validation failed.
The following will make a capture transaction and withdraw what you have reserved on cardholder’s bank account.
curl -X POST \
https://gateway.test.clearhaus.com/authorizations/84412a34-fa29-4369-a098-0165a80e8fda/captures \
-u <your-api-key>: \
-H "Signature: <signing-api-key> RS256-hex <signature>"
You can withdraw a partial amount by providing an amount
parameter:
curl -X POST \
https://gateway.test.clearhaus.com/authorizations/84412a34-fa29-4369-a098-0165a80e8fda/captures \
-u <your-api-key>: \
-d "amount=1000" \
-H "Signature: <signing-api-key> RS256-hex <signature>"
Example response (snippet):
{
"id": "d8e92a70-3030-4d4d-8ad2-684b230c1bed",
"status": {
"code": 20000
},
"processed_at": "2018-07-09T12:58:56+00:00",
"amount": 1000,
"_links": {
"authorization": {
"href": "/authorizations/84412a34-fa29-4369-a098-0165a80e8fda"
},
"refunds": {
"href": "/authorizations/84412a34-fa29-4369-a098-0165a80e8fda/refunds"
}
}
}
You can refund all money or a partial amount of what you have withdrawn from cardholder’s bank account:
curl -X POST \
https://gateway.test.clearhaus.com/authorizations/84412a34-fa29-4369-a098-0165a80e8fda/refunds \
-u <your-api-key>: \
-d "amount=500" \
-H "Signature: <signing-api-key> RS256-hex <signature>"
Example response (snippet):
{
"id": "f04c0872-47ce-4683-8d8c-e154221bba14",
"status": {
"code": 20000
},
"processed_at": "2018-07-09T12:58:56+00:00",
"amount": 500,
"_links": {
"authorization": { "href": "/authorizations/84412a34-fa29-4369-a098-0165a80e8fda" }
}
}
Sometimes cardholders should receive money, e.g. if you wish to pay out some winnings.
The following will transfer EUR 500.00 to cardholder’s bank account from your merchant bank account:
curl -X POST https://gateway.test.clearhaus.com/credits \
-u <your-api-key>: \
-d "amount=50000" \
-d "currency=EUR" \
-d "ip=1.1.1.1" \
-d "card[pan]=4111111111111111" \
-d "card[expire_month]=06" \
-d "card[expire_year]=2022" \
-H "Signature: <signing-api-key> RS256-hex <signature>"
Example response (snippet):
{
"id": "1b377999-bafb-42b0-a24f-106b312b0b40",
"status": {
"code": 20000
},
"processed_at": "2018-07-09T12:58:56+00:00",
"amount": 50000,
"currency": "EUR"
}
Depending on card scheme and merchant category, the name on the card might be
necessary for approval of credits. It may be provided through the optional
parameter card[name]
.
Clearhaus supports two types of subscription billing:
For both types, there may be an agreed end of the series and the amount may be varying. See the partner guideline for more details.
A first-in-series payment is created by making an authorization and
marking it as either a recurring
or unscheduled
series.
For instance, a first-in-series recurring payment could be made this way:
curl -X POST \
https://gateway.test.clearhaus.com/authorizations \
-u <your-api-key>: \
-d "amount=2050" \
-d "currency=EUR" \
-d "series[type]=recurring" \
-d "card[pan]=4111111111111111" \
-d "card[expire_month]=06" \
-d "card[expire_year]=2026" \
-d "card[csc]=123" \
--data-urlencode "card[3dsecure][v2][rreq]=<some-rreq-value>" \
-H "Signature: <signing-api-key> RS256-hex <signature>"
Example response (snippet):
{
"id": "1b722683-92ad-4c6b-85da-e119d550670d",
"status": { "code": 20000 },
"series": {
"type": "recurring",
"tid": "481048839682954"
}
}
This should be followed by a capture.
Subsequent-in-series authorizations initiated by the merchant are made similarly, however, CSC is not included, and the previous-in-series is referenced, e.g.:
curl -X POST \
https://gateway.test.clearhaus.com/authorizations \
-u <your-api-key>: \
-d "amount=2050" \
-d "currency=EUR" \
-d "series[previous][id]=1b722683-92ad-4c6b-85da-e119d550670d" \
-d "card[pan]=4111111111111111" \
-d "card[expire_month]=06" \
-d "card[expire_year]=2026" \
-H "Signature: <signing-api-key> RS256-hex <signature>"
A first-in-series authorization can also be made using the applepay
,
googlepay
or mobilepayonline
payment methods.
A subsequent-in-series authorization must be made using the card
payment
method with the exact card details of the referenced previous-in-series
authorization.
Any first-in-series authorization must be made with strong customer authentication (SCA) regardless of the authorization amount (when the cardholder is in scope for SCA).
3-D Secure is a protocol designed to improve security for online transactions. Before you continue please read more about this protocol at 3dsecure.io.
3-D Secure is the only way to achieve liability shift for fraud chargebacks.
To perform a 3-D Secure version 1 transaction you make an ordinary
authorization including a pares
value:
curl -X POST https://gateway.test.clearhaus.com/authorizations \
-u <your-api-key>: \
-d "amount=2050" \
-d "currency=EUR" \
-d "ip=1.1.1.1" \
-d "card[pan]=4111111111111111" \
-d "card[expire_month]=06" \
-d "card[expire_year]=2022" \
-d "card[csc]=123" \
--data-urlencode "card[3dsecure][v1][pares]=<some-pares-value>" \
-H "Signature: <signing-api-key> RS256-hex <signature>"
Example response (snippet):
{
"id": "84412a34-fa29-4369-a098-0165a80e8fda",
"status": {
"code": 20000
},
"processed_at": "2018-07-09T12:58:56+00:00",
"3dsecure": {
"version": "1.0.2",
"status": "Y"
}
}
To perform a 3-D Secure version 2 transaction you make an ordinary
authorization including an ares
or an rreq
value. The former is used in the
following example:
curl -X POST https://gateway.test.clearhaus.com/authorizations \
-u <your-api-key>: \
-d "amount=2050" \
-d "currency=EUR" \
-d "ip=1.1.1.1" \
-d "card[pan]=4111111111111111" \
-d "card[expire_month]=06" \
-d "card[expire_year]=2022" \
-d "card[csc]=123" \
--data-urlencode "card[3dsecure][v2][ares]=<some-ares-value>" \
-H "Signature: <signing-api-key> RS256-hex <signature>"
Example response (snippet):
{
"id": "d0949241-1ee8-47da-a77c-d251fd9e1e88",
"status": {
"code": 20000
},
"processed_at": "2020-07-03T11:06:58+00:00",
"3dsecure": {
"version": "2.1.0",
"status": "Y"
}
}
Notice: The response element threed_secure
is deprecated,
please use 3dsecure
.
Some basic account information can be fetched:
curl https://gateway.test.clearhaus.com/account \
-u <your-api-key>:
Example response (snippet):
{
"merchant_id": "000000003000001",
"name": "Merchant Ltd.",
"country": "GB",
"mcc": "1111",
"descriptor": "merchant.com",
"transaction_rules":"reject authorization if amount > 100 EUR and (not fully 3dsecure)",
"acquirer": {
"visa_bin": 438309,
"mastercard_bin": 526571
}
}
See account resource documentation for further details.
Our API offers six different resources:
To reserve money on a cardholder’s bank account you make a new authorization resource.
POST https://gateway.clearhaus.com/authorizations
Authorizations can be created using different payment methods:
card
, applepay
, mobilepayonline
, moto
, vipps
.
Exactly one payment method must be used.
store
|use
)
store
: The payment credential will be stored; it may only be
stored if the authorization is approved.
use
: The payment credential has already been stored and is now
being used.
use
, if initiator
is merchant
(store
is invalid),store
, if the authorization is first-in-series.cardholder
|merchant
)
credential_on_file=store
before initiator
may be
merchant
.
merchant
, if the authorization is
subsequent-in-series (cardholder
is invalid),cardholder
, otherwise.recurring
|unscheduled
)
series[previous][...]
.
recurring
: A series of transactions where the cardholder has
explicitly agreed that the merchant may repeatedly charge the cardholder at
regular, predetermined intervals that may not exceed 1 year.
unscheduled
: A series of transactions where the cardholder has
explicitly agreed that the merchant may repeatedly charge the cardholder at
non-predetermined times, e.g. based on cardholder usage.
series[previous]
is present.series[type]
.
card
.
series[type]
is present.series
.
series
or
initiator
.
Notice: When recurring
is used, Clearhaus automatically
identifies if there was a previous-in-series and if that is the case uses the
level of authentication (CSC, 3-D Secure, etc.) to conclude if the payment is
a first-in-in-series or a subsequent-in-series recurring.
Notice: Since series[type]
cannot be supplied together
with series[previous]
, the type of a series cannot change.
card
card[3dsecure][v1][pares]
.
Notice: An authorization that includes
card[3dsecure][v1][pares]
, card[3dsecure][v2][rreq]
,
and/or card[csc]
cannot be a subsequent-in-series authorization.
applepay
Apple Pay requires the payment details (PAN, expiry, etc.) of the payment token
to be decrypted by a symmetric key.
Your systems must derive this symmetric key using the payment token’s ephemeral
public key, the merchant’s private key and the merchant ID. For this, we refer
to our reference implementation written
in Ruby; see Apple’s documentation for the PaymentToken
object for more information.
PKPaymentToken
serialized as JSON, supplied as a string.
{"paymentData":{"version":"EC_v1","data":"",...},"paymentMethod":{...},...}
data
from the PKPaymentToken
.
Additionally, an Apple Pay authorization can be created using raw values from a payment token:
onlinePaymentCryptogram
in
the payment token.
eciIndicator
in the
payment token.
Notice: Signing is required to use the applepay
payment
method.
Notice: An authorization made with applepay
is
strongly authenticated (SCA in PSD2).
Notice: An authorization made with applepay
may be 3-D
Secured to some degree or not at all; this is indicated by the
eciIndicator
of the applepay[payment_token]
.
Notice: An authorization made with applepay
cannot be a
subsequent-in-series authorization.
Notice: Clients using applepay[raw]
are responsible for
verifying the payment token’s signature, decrypting the token’s payment data,
validating the format of the fields in the payment data, etc. The procedure
is available in Apple Pay’s
Payment Token Format Reference.
googlepay
To accept a payment using Google Pay, the complete payment token, recipient ID
and derived shared secret, are required. Please refer to the official
documentation. Only protocol version ECv2
is
supported.
merchant:0123456789
.
Notice: Signing is required to use the googlepay
payment
method.
Notice: An authorization made with googlepay
is strongly
authenticated (SCA in PSD2) if authMethod
is
CRYPTOGRAM_3DS
and the Google Pay guidelines for SCA
(link)
have been followed.
If authMethod
is PAN_ONLY
, a 3-D Secure flow is
required for SCA.
Notice: An authorization made with googlepay
cannot be a
subsequent-in-series authorization.
Notice: The recipient_id
for the googlepay
test environment is merchant:12345678901234567890
.
mobilepayonline
payment_token
parameter is included, the pan
must be a Token PAN.
{"paymentId":"string","tokenData":{"cryptogramInfo":{...},...},...}
mobilepayonline[3dsecure][v1][pares]
.
Notice: Signing is required to use the mobilepayonline
payment method.
Notice: An authorization made with mobilepayonline
is
strongly authenticated (SCA in PSD2).
moto
Notice: Signing is required to use the moto
payment
method.
Notice: Neither series[]
(nor recurring
)
nor credential_on_file
is supported.
Also, initiator
cannot be merchant
.
vipps
{"pspTransactionId":"string","networkToken":{"cryptogram": "string",...},...}
Notice: Signing is required to use the vipps
payment method.
[3dsecure]
Only one 3-D Secure version can be used for a given authorization.
v2
is present.v1
is present.[3dsecure][v1]
Notice: A valid PARes can indicate three different levels: non-authenticated, attempted 3-D Secure, fully 3-D Secure.
[3dsecure][v2]
authenticationValue
, dsTransID
, etc.
rreq
is present.authenticationValue
, dsTransID
, etc.
ares
is present.If the previous-in-series authorization was made via this API, you should use
series[previous][id]
to reference it. If it was not made via this API, you
must obtain explicit approval from Clearhaus to use the raw scheme values
grouped in series[previous][mastercard]
and
series[previous][visa]
. This is relevant when moving a subscription
from another acquirer to Clearhaus or among Clearhaus accounts.
The Mastercard specific reference to the series contains the following parts.
recurring
|unscheduled
)
recurring
.
series[previous][id]
or
any series[previous][visa][...]
is present.
series[previous][mastercard][...]
is present.
Cannot be present if
series[previous][id]
or
any series[previous][visa][...]
is present.
fixed_amount_series
|variable_amount_series
)
fixed_amount_series
:
The series is a fixed-amount series. (MPMI value 03
.)
variable_amount_series
:
The series is a variable-amount series. (MPMI value 01
.)
A Mastercard exemption (not formally an acquirer exemption for
SCA) indicating that the transaction is out of scope for SCA.
01
indicates variable amount whereas 03
indicates fixed amount.
series[previous][id]
.
series[previous][mastercard][...]
is present.
Cannot be present if
series[previous][id]
or
any series[previous][visa][...]
is present.
The Visa specific reference to the series contains the following parts.
recurring
|unscheduled
)
recurring
.
series[previous][id]
or
any series[previous][mastercard][...]
is present.
series[previous][visa][type]
is present.
Cannot be present if
series[previous][id]
or
any series[previous][mastercard][...]
is present.
Notice: A series migrated to Clearhaus using these scheme references
cannot be continued with the now deprecated recurring
flag.
Instead, the subsequent-in-series following an authorization created using
scheme references must use series[previous][id]
to point to the
previous in series.
To transfer money from a cardholder’s bank account to your merchant bank account you make a new capture resource. You can make multiple captures for an authorization transaction.
POST https://gateway.clearhaus.com/authorizations/:id/captures
text_on_statement
from authorization.
Notice: A capture cannot be made if the authorization is 180 days old or older.
At most one type of travel data can be supplied for a capture; if travel
is
supplied, it must include exactly one of travel[car]
, travel[flight]
, or
travel[lodging]
.
For service type [car]
(rental), the following parameter is relevant.
For service type [flight]
, the following parameter is relevant.
For service type [lodging]
the following parameter is relevant.
To refund money to a cardholder’s bank account you make a new refund resource. You can make multiple refunds for an authorization transaction.
POST https://gateway.clearhaus.com/authorizations/:id/refunds
text_on_statement
from authorization.
Notice: A refund does not “free up” what is captured from the authorization; that is, after authorizing 10, capturing 5 and refunding 5, you can still only capture 5.
Notice: A refund cannot be made if the last capture is 180 days old.
To release reserved money on a cardholder’s bank account you make a new void resource. A reservation usually lasts for at least seven days depending on the issuing bank and is then automatically released.
POST https://gateway.clearhaus.com/authorizations/:id/voids
No parameters are needed to make a new void transaction.
Notice: A void cannot be made if the authorization age is 30 days or more.
To payout (e.g. winnings and not refunds) money to a cardholder’s bank account you make a new credit resource.
POST https://gateway.clearhaus.com/credits
Notice: Implicitly, initiator
is merchant
and
credential_on_file
is use
.
The account resource holds basic merchant account information. Only HTTP GET
is supported for this endpoint.
GET https://gateway.clearhaus.com/account
text_on_statement
.
When you make a new transaction, the JSON response includes one of the status codes in the following table. The rightmost columns indicate which transaction types a particular status code can be received for.
Status | code |
Meaning | Auth | Capture | Refund | Void | Credit |
---|---|---|---|---|---|---|---|
Approved | 20000 | Approved | ✓ | ✓ | ✓ | ✓ | ✓ |
Declined | 40000 | General input error | ✓ | ✓ | ✓ | ✓ | ✓ |
40110 | Invalid card number | ✓ | ✓ | ||||
40111 | Unsupported card scheme | ✓ | ✓ | ||||
40120 | Invalid CSC | ✓ | |||||
40130 | Invalid expire date | ✓ | ✓ | ||||
40135 | Card expired | ✓ | ✓ | ||||
40140 | Invalid currency | ✓ | ✓ | ||||
40150 | Invalid text on statement | ✓ | ✓ | ✓ | ✓ | ||
40200 | Clearhaus rule violation | ✓ | ✓ | ✓ | ✓ | ✓ | |
40300 | 3-D Secure problem | ✓ | |||||
40310 | 3-D Secure authentication failure | ✓ | |||||
40400 | Backend problem | ✓ | ✓ | ✓ | |||
40410 | Declined by issuer or card scheme | ✓ | ✓ | ✓ | |||
40411 | Card restricted | ✓ | ✓ | ||||
40412 | Card lost or stolen | ✓ | ✓ | ||||
40413 | Insufficient funds | ✓ | ✓ | ||||
40414 | Suspected fraud | ✓ | ✓ | ||||
40415 | Amount limit exceeded | ✓ | ✓ | ||||
40416 | Additional authentication required | ✓ | ✓ | ||||
40420 | Merchant blocked by cardholder | ✓ | ✓ | ||||
50000 | Clearhaus error | ✓ | ✓ | ✓ | ✓ | ✓ |
A status message may be included in the response when you create a new transaction. The status message can be used for debugging and may include a more specific error message.
Status messages should be shown to the merchant.
Examples:
{
"status": {
"code": 40000,
"message": "parameter 'amount' is required"
}
}
{
"status": {
"code": 40200,
"message": "amount > 100 EUR and (not strongly authenticated)"
}
}
{
"status": {
"code": 40200,
"message": "not (fully 3dsecure or subsequent recurring)"
}
}
A merchant blocked by cardholder status code is both a decline of the current authorization, but also a notice to halt all future merchant-initiated-transactions on this card from this merchant. This includes, but is not limited to, recurring transactions.
Only after the blockade has been lifted, by actions taken by the cardholder, may transactions be resumed.
For testing towards the test endpoint gateway.test.clearhaus.com
please use
PANs that are either not
Luhn-compliant, are
one of the special test PANs 2221000000000009, 4111111111111111,
5000000000000004, or are Apple Pay test cards.
For PANs starting with 420000 and ending with 0000, and PANs starting with
555555 and ending with 4444, you can specify a valid status code
as
transaction amount to trigger the status; any other transaction amount will
result in 40110.
When testing towards the test endpoint, the CSC 987—and only 987—is considered a match for all PANs.
# authorizations
https://gateway.clearhaus.com/authorizations
# captures
https://gateway.clearhaus.com/authorizations/:id/captures
# voids
https://gateway.clearhaus.com/authorizations/:id/voids
# refunds
https://gateway.clearhaus.com/authorizations/:id/refunds
# credits
https://gateway.clearhaus.com/credits
# account
https://gateway.clearhaus.com/account
Follow coming changes on the source code repository.
Sorted by descending timestamp.
Travel data can be supplied for a capture as of 2022-02-11.
The currency VES will not be supported after 2021-10-01T04:00:00Z.
Replace recurring
with series[type]=recurring
and add series[previous]
as
a way of pointing to the previous-in-series authorization (either via a
Clearhaus authorization ID or via raw scheme values).
Add also two optional parameters credential_on_file
and initiator
to allow
for explicitly specifying if credential on file is being stored or used, and if
the transaction is merchant or cardholder initiated.
Support for multiple signatures for request signing will be removed any time after 2020-10-31.
Starting 2020-07-08 support for 3-D Secure version 2 has been added. See 3-D Secure and Authentication: [3dsecure].
threed_secure
response elementThe response element threed_secure
is now deprecated; it will be available at
least until 2021-02-15.
Starting 2020-03-03 the optional parameter card[name]
may be used to provide
the name on the card for credits. Depending on card scheme and merchant
category, the name might be necessary for approval.
In the first quarter of 2020 signing of POST requests will become mandatory. We will work together with clients to ensure their requests are compliant before introducing enforcement of the requirement in the transaction gateway.