The time at which this data payload was valid. When sending events in realtime, this will usually be 'now'. This is used to merge data that arrives out-of-order.
A Unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
A unique identifier for this order.
|
The unique identifier of the customer. If your system allows anonymous
checkout then we recommend making this the customer's email address.
|
An eventType should identify what event in your system triggered this API call.
Pattern: ^[a-zA-Z0-9][a-zA-Z0-9-_]*$
|
Deprecated. Use customerId instead.
|
A unique identifier for this payment method, specific to this customer. Two customers should not use the same paymentMethodId. Prefer {"paymentMethod": {"methodType": "cash"}} instead of paymentMethodId for cash payments.
|
|
|
|
Card - A credit or debit card.
Show definition
|
Card payment method indicator.
One of:
card - Card payment method indicator. Used for both credit and debit cards.creditcard - Deprecated. Use card.debitcard - Deprecated. Use card.
|
A unique identifier for this payment method, specific to this customer. Two
customers should not use the same paymentMethodId.
|
The card network or scheme, such as visa or mastercard. Ravelin will identify the scheme on your behalf if you send the cardBin, which should be preferred.
|
A unique identifier for the physical card, shared between customers. Used
to link cards in Connect. Must not be a hash of the PAN.
If you use multiple PSPs who each generate their own equivalent of an
instrumentId, you should consider prefixing their values to indicate
their origin to avoid collisions. Common examples include Stripe's
fingerprint,
or Braintree's
unique_number_identifier).
|
The full Primary Account Number of the card.
This should be 14-19 digits. For example 1234123412341234. This should not contain hyphens or spaces.
Used by Ravelin to generate the instrumentId for this card.
If specified, you do not need to provide instrumentId, cardBin or cardLastFour.
Only PCI DSS SAQ-D certified merchants should submit the PAN to Ravelin. You must not send requests
containing this field to api.ravelin.com, and must instead use pci.ravelin.com.
Please see our PCI DSS documentation for more information.
|
The first six or eight digits of the card number/PAN. The Bank Identification
Number (BIN), recently more commonly known as the Issuer
Identification Number (IIN).
Given the BIN, Ravelin will populate the issuer, country of issuance,
and card type on your behalf.
|
The last four digits of the card number/PAN. Please note this will be truncated to the last two digits when an eight digit BIN is provided.
|
The card issuer, who the true cardholder will report fraud to. Ravelin
will identify the issuer on your behalf if you send the cardBin,
which should be preferred.
|
Whether this is a prepaid debit card. Ravelin will identify whether
the card is prepaid on your behalf if you send the cardBin which
should be preferred.
|
The country that the card was issued in. Ravelin will identify the
country of issuance on your behalf if you send the cardBin, which
should be preferred.
A ISO 3166-1 Alpha 3
or Alpha 2 country
code.
|
The expiry month of the card.
|
The expiry year of the card.
|
|
|
The address of the registered cardholder, as used to pass
AVS
checks. It is common to have fewer location details for this address,
but provide what you have.
|
|
|
The postal or zip code. If provided without latitude or longitude, Ravelin will perform coarse geolocation in some countries.
|
The latitude of the location.
|
The longitude of the location.
|
The name of the person that will accept delivery of goods to this address.
|
The street address of the location.
|
The street address of the location.
|
The neighbourhood of the location.
|
The zone of the location.
|
|
|
The state/county of the location.
|
The PO box number related to the location.
|
Custom data that is relevant to your domain. This can be any json object.
Please include any details that you think are relevant to fraud that our
schema does not capture.
|
The geohash of the location.
|
|
Whether this payment method is a corporate card.
|
Whether this payment method is a virtual card.
|
Whether the card was successfully registered with your gateway/PSP.
|
The time that the card was saved to the customer's account. (Not the card start date.)
A Unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
The time at which the payment method was last verified by the customer.
An example mechanism would be a random amount charged to the
customer's card that they can confirm the amount of.
A Unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
Whether the card has been compromised.
|
The reason why the card is considered compromised.
One of:
cloned, databreach, found, lost, stolen, frozen, defrosted, or uncompromised.
|
Custom data that is relevant to your domain. This can be any json object.
Please include any details that you think are relevant to fraud that our
schema does not capture.
|
active
boolean
optional
deprecated
Whether this card is still saved to the customer's account.
|
banned
boolean
optional
deprecated
Whether this card has been banned.
|
The e-Wallet to which the customer associated the card.
One of:
applepay, googlepay, samsungpay, amazonpay, or visacheckout.
|
The nickname the customer has given the payment method.
|
The card network or scheme, such as visa or mastercard. Ravelin
will identify the cardType on your behalf if you send the cardBin,
which should be preferred.
|
|
|
Payment Method Cipher - An encrypted payment method, containing the full card details encrypted via a
Ravelin SDK.
Show definition
|
Client-side encrypted card payment method indicator.
Only:
paymentMethodCipher.
|
The card ciphertext produced by the Ravelin SDK card encryption.
This field constitutes cardholder data, and submission of this field therefore requires PCI DSS
SAQ-A or SAQ-AEP certification. You must not send requests containing this field to
api.ravelin.com, and must instead use pci.ravelin.com.
Please see our PCI DSS documentation for more information.
|
The AES Key ciphertext produced by the Ravelin SDK card encryption.
|
The algorithm used to generate the ciphertexts.
|
A unique identifier for this payment method, specific to this customer. Two
customers should not use the same paymentMethodId.
|
The version of the Ravelin SDK that performed this encryption.
|
The index of the public RSA key used to encrypt the card.
|
An identifier for the public key used during encryption.
|
|
Show definition
|
|
|
The postal or zip code. If provided without latitude or longitude, Ravelin will perform coarse geolocation in some countries.
|
The latitude of the location.
|
The longitude of the location.
|
The name of the person that will accept delivery of goods to this address.
|
The street address of the location.
|
The street address of the location.
|
The neighbourhood of the location.
|
The zone of the location.
|
|
|
The state/county of the location.
|
The PO box number related to the location.
|
Custom data that is relevant to your domain. This can be any json object.
Please include any details that you think are relevant to fraud that our
schema does not capture.
|
The geohash of the location.
|
|
When the payment method was added to the customer's account. Note: this is not the card start date.
A Unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
The version of the ravelinjs library that performed this encryption.
|
|
|
Cash - The customer is paying in cash, or a cash-based payment method.
Show definition
|
Indicator of a cash payment, or cash-based payment method (e.g. paysafecard).
Only:
cash.
|
The name of the cash-based payment service used, if applicable.
|
|
|
Bank Account - Bank Accounts.
Show definition
|
Bank account payment method indicator.
Only:
bankaccount.
|
A unique identifier for this payment method, specific to this customer. Two
customers should not use the same paymentMethodId.
|
The type of transfer: whether the customer is initiating the payment, or you are withdrawing funds from the customer's bank account based on an agreement to initiate payments on their behalf. Use "push" for a customer-initiated payment (e.g. a bank transfer) and "pull" for a merchant-initiated payment (e.g. Direct Debit).
One of:
push, or pull.
|
The name of the payment scheme or instrument used for the transfer of funds.
|
IBAN (International Bank Account Number)
Following the ISO 13616:2007 standard.
|
|
|
|
Show definition
|
|
|
The postal or zip code. If provided without latitude or longitude, Ravelin will perform coarse geolocation in some countries.
|
The latitude of the location.
|
The longitude of the location.
|
The name of the person that will accept delivery of goods to this address.
|
The street address of the location.
|
The street address of the location.
|
The neighbourhood of the location.
|
The zone of the location.
|
|
|
The state/county of the location.
|
The PO box number related to the location.
|
Custom data that is relevant to your domain. This can be any json object.
Please include any details that you think are relevant to fraud that our
schema does not capture.
|
The geohash of the location.
|
|
The type of the account.
One of the following:
SAVINGS: A savings account, which is designed to help customers save money and earn interest.CURRENT: A checking account, which is designed for frequent transactions and typically has low or no interest rates.
|
The name of the account owner.
|
The type of customer or entity that the account is associated with, whether it's an individual or a business.
One of the following:
PERSONAL: A bank account owned and used by an individual for personal transactions. Can include joint accounts.BUSINESS: A bank account owned by a company or organisation for business transactions.
|
Code assigned by central bank to identify bank that account is associated with.
Multiple bank code formats are supported.
|
Name of bank which account belongs to.
|
BIC - business identifier code for banks and other institutions.
Following the ISO9362 standard.
|
The account number issued by the bank.
|
The nickname for the payment method that the customers gives, if applicable.
|
The time that the card was saved to the customer's account. (Not the card start date.)
A Unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
Custom data that is relevant to your domain. This can be any json object.
Please include any details that you think are relevant to fraud that our
schema does not capture.
|
|
|
PayPal - PayPal payments.
Show definition
|
PayPal payment method indicator.
Only:
paypal.
|
A unique identifier for this payment method, specific to this customer. Two
customers should not use the same paymentMethodId.
|
|
|
|
|
The address of the account holder. It is common to have fewer location
details for this address, but provide what you have.
|
|
|
The postal or zip code. If provided without latitude or longitude, Ravelin will perform coarse geolocation in some countries.
|
The latitude of the location.
|
The longitude of the location.
|
The name of the person that will accept delivery of goods to this address.
|
The street address of the location.
|
The street address of the location.
|
The neighbourhood of the location.
|
The zone of the location.
|
|
|
The state/county of the location.
|
The PO box number related to the location.
|
Custom data that is relevant to your domain. This can be any json object.
Please include any details that you think are relevant to fraud that our
schema does not capture.
|
The geohash of the location.
|
|
The time that the card was saved to the customer's account. (Not the card start date.)
A Unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
The time at which the payment method was last verified by the customer.
An example mechanism would be a random amount charged to the
customer's card that they can confirm the amount of.
A Unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
The nickname for the payment method that the customer gives, if applicable.
|
|
|
|
|
Custom data that is relevant to your domain. This can be any json object.
Please include any details that you think are relevant to fraud that our
schema does not capture.
|
banned
boolean
optional
deprecated
If the payment method has been banned
|
active
boolean
optional
deprecated
Whether the payment method is active for use by this account
|
|
|
Credit - This payment method type should be used for any payments made using credit that a customer has with the merchant.
Show definition
|
Credit payment method indicator.
Only:
credit.
|
A unique identifier for this payment method, specific to this customer. Two
customers should not use the same paymentMethodId.
|
The name of the store credit scheme used as a payment method, if applicable.
|
When the payment method was added to the customer's account.
A Unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
A Unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
Custom data that is relevant to your domain. This can be any json object.
Please include any details that you think are relevant to fraud that our
schema does not capture.
|
|
|
Invoice - This payment method should be used whenever the merchant provides credit to the customer.
Show definition
|
Invoice payment method indicator.
Only:
invoice.
|
A unique identifier for this payment method, specific to this customer. Two
customers should not use the same paymentMethodId.
|
The name of the invoice or 'buy now, pay later' scheme used, if applicable.
|
When the payment method was added to the customer's account.
A Unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
A Unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
The nickname for the payment method that the customers gives, if applicable.
|
|
Show definition
|
|
|
The postal or zip code. If provided without latitude or longitude, Ravelin will perform coarse geolocation in some countries.
|
The latitude of the location.
|
The longitude of the location.
|
The name of the person that will accept delivery of goods to this address.
|
The street address of the location.
|
The street address of the location.
|
The neighbourhood of the location.
|
The zone of the location.
|
|
|
The state/county of the location.
|
The PO box number related to the location.
|
Custom data that is relevant to your domain. This can be any json object.
Please include any details that you think are relevant to fraud that our
schema does not capture.
|
The geohash of the location.
|
|
The email address used by the customer to register an invoice or 'buy now, pay later' payment method.
|
Custom data that is relevant to your domain. This can be any json object.
Please include any details that you think are relevant to fraud that our
schema does not capture.
|
|
|
Wallet - A digital wallet payment method.
Show definition
|
Wallet payment method indicator.
Only:
wallet.
|
A unique identifier for this payment method, specific to this customer. Two
customers should not use the same paymentMethodId.
|
The name of the digital wallet scheme or electronic payment service.
For common wallets, please send the official name only, for example
applepay or googlepay.
|
The card network or scheme of the card used within a wallet payment method,
such as visa or mastercard. Ravelin will identify the cardScheme on your behalf
if you send the cardBin, which should be preferred.
|
A unique identifier for the physical card, shared between customers. Used
to link cards in Connect. Must not be a hash of the PAN or DPAN.
If you use multiple PSPs who each generate their own equivalent of an
instrumentId, you should consider prefixing their values to indicate
their origin to avoid collisions. Common examples include Stripe's
fingerprint,
or Braintree's
unique_number_identifier).
|
The full Primary Account Number of the card.
This should be 14-19 digits. For example 1234123412341234. This should not contain hyphens or spaces.
Used by Ravelin to generate the instrumentId for this card.
If specified, you do not need to provide instrumentId, cardBin or cardLastFour.
Only PCI DSS SAQ-D certified merchants should submit the PAN to Ravelin. You must not send requests
containing this field to api.ravelin.com, and must instead use pci.ravelin.com.
Please see our PCI DSS documentation for more information.
|
The first six digits of the card number/PAN or DPAN. The Bank Identification
Number (BIN), recently also known as the Issuer
Identification Number (IIN).
If you have access to the card data within the wallet, then given the
cardBIN Ravelin will populate the issuer, countryIssued, and
cardType on your behalf.
|
The last four digits of the card number/PAN or DPAN.
|
The card network or scheme, such as visa or mastercard. Should
only be sent if you have access to the card data within the wallet,
rather than just the DPAN. Ravelin will identify the cardType on
your behalf if you send the cardBin, which should be preferred.
|
The card issuer, who the true cardholder will report fraud to. Should
only be sent if you have access to the card data within the wallet,
rather than just the DPAN. Ravelin will identify the issuer on your
behalf if you send the cardBin, which should be preferred.
|
Whether this is a prepaid debit card. Should only be sent if you have
access to the card data within the wallet, rather than just the DPAN.
Ravelin will identify the prepaidCard status on your behalf if you
send the cardBin, which should be preferred.
|
The country that the card was issued in. Should only be sent if you
have access to the card data within the wallet, rather than just the
DPAN. Ravelin will identify the countryIssued on your behalf if you
send the cardBin, which should be preferred.
A ISO 3166-1 Alpha 3
or Alpha 2 country code.
|
The expiry month of the card.
|
The expiry year of the card.
|
|
|
The address of the registered cardholder, as used to pass
AVS
checks. It is common to have fewer location details for this address,
but provide what you have.
|
|
|
The postal or zip code. If provided without latitude or longitude, Ravelin will perform coarse geolocation in some countries.
|
The latitude of the location.
|
The longitude of the location.
|
The name of the person that will accept delivery of goods to this address.
|
The street address of the location.
|
The street address of the location.
|
The neighbourhood of the location.
|
The zone of the location.
|
|
|
The state/county of the location.
|
The PO box number related to the location.
|
Custom data that is relevant to your domain. This can be any json object.
Please include any details that you think are relevant to fraud that our
schema does not capture.
|
The geohash of the location.
|
|
Whether the card was successfully registered with your gateway/PSP.
|
The time that the card was saved to the customer's account. (Not the card start date.)
A Unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
The time at which the payment method was last verified by the customer.
An example mechanism would be a random amount charged to the
customer's card that they can confirm the amount of.
A Unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
A Google Pay specific field, which is available in the
AssuranceDetailsSpecifications
object from the Google Pay API. If true, indicates that cardholder possession has been validated.
We strongly recommend that you send this data for Google Pay transactions if you have access to this field.
|
A Google Pay specific field, which is available in the
AssuranceDetailsSpecifications
object from the Google Pay API. If true, indicates that identification and verification was performed.
We strongly recommend that you send this data for Google Pay transactions if you have access to this field.
|
The email address associated with the account where the wallet is set up. For example, this would be an @gmail.com email address for Google Pay wallets, or the email address associated with the Apple ID for Apple Pay wallets. In some cases a temporary email address may be used, for example, for Apple Pay this may be an @privaterelay.appleid.com email address.
|
Custom data that is relevant to your domain. This can be any json object.
Please include any details that you think are relevant to fraud that our
schema does not capture.
|
active
boolean
optional
deprecated
Whether this card is still saved to the customer's account.
|
banned
boolean
optional
deprecated
Whether this card has been banned.
|
The nickname the customer has given the payment method.
|
|
|
From Transaction - Refer to the payment method used by a named transaction.
For usage examples, see
Saving payment methods after checkout
and Associating refunds with payment methods.
Show definition
|
Indicator for using a payment method from another transaction.
Only:
fromTransaction.
|
The transaction ID to look up the payment method from.
|
The gateway that the transaction was processed through.
|
The gateway ref provided by the gateway for the transaction.
|
|
|
|
|
Direct Debit - Direct Debits. - deprecated.
Show definition
|
Direct Debit payment method indicator.
Only:
directdebit.
|
A unique identifier for this payment method, specific to this customer. Two
customers should not use the same paymentMethodId.
|
|
|
The type of direct debit scheme.
One of:
autogiro, bacs, becs, becsnz, betalingsservice, or sepa.
|
IBAN (International Bank Account Number)
Following the ISO 13616:2007 standard.
|
|
|
|
Show definition
|
|
|
The postal or zip code. If provided without latitude or longitude, Ravelin will perform coarse geolocation in some countries.
|
The latitude of the location.
|
The longitude of the location.
|
The name of the person that will accept delivery of goods to this address.
|
The street address of the location.
|
The street address of the location.
|
The neighbourhood of the location.
|
The zone of the location.
|
|
|
The state/county of the location.
|
The PO box number related to the location.
|
Custom data that is relevant to your domain. This can be any json object.
Please include any details that you think are relevant to fraud that our
schema does not capture.
|
The geohash of the location.
|
|
The name of the account owner.
|
Code assigned by central bank to identify bank that account is associated with.
Multiple bank code formats are supported.
|
Name of bank which account belongs to.
|
BIC - business identifier code for banks and other institutions.
Following the ISO9362 standard.
|
The account number issued by the bank.
|
The unique reference issued for the direct debit mandate.
|
A URL to access the direct debit mandate agreement.
|
The nickname for the payment method that the customers gives, if applicable.
|
Custom data that is relevant to your domain. This can be any json object.
Please include any details that you think are relevant to fraud that our
schema does not capture.
|
|
|
Bank Transfer - Bank Transfers. - deprecated.
Show definition
|
Bank transfer payment method indicator.
Only:
banktransfer.
|
A unique identifier for this payment method, specific to this customer. Two
customers should not use the same paymentMethodId.
|
One of:
bancontact, eps, giropay, ideal, inghomepay, sofort, or sepa.
|
IBAN (International Bank Account Number)
Following the ISO 13616:2007 standard.
|
|
|
|
Show definition
|
|
|
The postal or zip code. If provided without latitude or longitude, Ravelin will perform coarse geolocation in some countries.
|
The latitude of the location.
|
The longitude of the location.
|
The name of the person that will accept delivery of goods to this address.
|
The street address of the location.
|
The street address of the location.
|
The neighbourhood of the location.
|
The zone of the location.
|
|
|
The state/county of the location.
|
The PO box number related to the location.
|
Custom data that is relevant to your domain. This can be any json object.
Please include any details that you think are relevant to fraud that our
schema does not capture.
|
The geohash of the location.
|
|
The name of the account owner.
|
Code assigned by central bank to identify bank that account is associated with.
Multiple bank code formats are supported.
|
Name of bank which account belongs to.
|
BIC - business identifier code for banks and other institutions.
Following the ISO9362 standard.
|
The account number issued by the bank.
|
The nickname for the payment method that the customers gives, if applicable.
|
The time that the card was saved to the customer's account. (Not the card start date.)
A Unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
Custom data that is relevant to your domain. This can be any json object.
Please include any details that you think are relevant to fraud that our
schema does not capture.
|
|
|
Other - Other supported payment methods. - deprecated.
Show definition
|
Other payment method type indicator.
One of:
voucher, bitcoin, transfer, paysafe, cheque, or edenred.
|
A unique identifier for this payment method, specific to this customer. Two
customers should not use the same paymentMethodId.
|
When the payment method was added to the customer's account.
A Unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
A Unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
Custom data that is relevant to your domain. This can be any json object.
Please include any details that you think are relevant to fraud that our
schema does not capture.
|
The nickname for the payment method that the customers gives, if applicable.
|
banned
boolean
optional
deprecated
If the payment method has been banned
|
active
boolean
optional
deprecated
Whether the payment method is active for use by this account
|
|
|
Removal: Used for marking a saved payment method as removed from the account.
Show definition
|
A unique identifier for this payment method, specific to this customer. Two
customers should not use the same paymentMethodId.
|
False to indicate the payment method has been deactivated.
Only:
false.
|
|
The device used by the customer to trigger this update.
|
The ID of the device used by the customer to trigger this update.
|
The IP address of the device connecting to your services. Used in fraud and account-takeover detection.
When extracting this IP address, consider X-Forwarded-For.
|
|
|
The browser user-agent string, if the device represents a web browser - window.navigator.userAgent.
|
|
|
The operating system that the device is running.
|
One of:
computer, phone, or tablet.
|
|
|
The geolocated position of the device.
|
|
|
The postal or zip code. If provided without latitude or longitude, Ravelin will perform coarse geolocation in some countries.
|
The latitude of the location.
|
The longitude of the location.
|
The name of the person that will accept delivery of goods to this address.
|
The street address of the location.
|
The street address of the location.
|
The neighbourhood of the location.
|
The zone of the location.
|
|
|
The state/county of the location.
|
The PO box number related to the location.
|
Custom data that is relevant to your domain. This can be any json object.
Please include any details that you think are relevant to fraud that our
schema does not capture.
|
The geohash of the location.
|
|
Custom data that is relevant to your domain. This can be any json object.
Please include any details that you think are relevant to fraud that our
schema does not capture.
|
The name of the web browser being used, if applicable. Prefer userAgent.
|
Whether Javascript is enabled on the web browser.
|
Whether cookies are enabled on the web browser.
|
The resolution of the screen on the device in the format XxY
|
|
The ID of the device used by the customer to trigger this update.
|
An attempt to charge a payment method to pay or be refunded for an order. Mutually exclusive with transactions.
|
The currency of the amount of this transaction, as an ISO 4217 currency code.
Pattern: ^[a-zA-Z]{3}$
|
A unique identifier for the transaction.
Required when sending a transaction before talking to the PSP, because the alternative gatewayReference cannot be known. If telling Ravelin about the transaction after processing it (as with a refund, for example) transactionId can be omitted in place of gateway and gatewayReference.
|
The time that the transaction is being attempted.
A Unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
|
|
The type of transaction interacting with the payment method.
auth: An auth transaction is used to reserve funds on the customer's card without yet deducting it. Useful to verify whether the customer has sufficient funds in their account and reserving a limit when the final order price cannot be known. Sometimes known as a pre-auth.capture: A capture transaction is used to immediately deduct authorised funds (up to the amount auth'd) from a customer's card.auth_capture: A simultaneous combination of auth and capture in one transaction, for when there is no need to separately auth then capture. Typical with straightforward "buy now"-style checkout.refund: A refund transaction credits a customer's payment method. If you do not know the payment method ID you are refunding to, but do know the original transaction, see Associating refunds with payment methods.void: A void transaction is the explicit discarding of authorization of funds.use, redeem: Deprecated. See voucherRedemption on /v2/chargeback or /v2/paymentmethod/voucher.
One of:
preauth, auth, capture, auth_capture, void, refund, redeem, or use.
|
The gateway responsible for processing the transaction. Used to link to chargebacks. Usually only available after attempting the payment.
|
The reference given to this transaction by the processing gateway. Used to link to chargebacks. Usually only available after attempting the payment. Each transaction should have a unique gateway reference.
|
Whether the transaction successfully completed with no error.
|
Details on how 3D Secure (3DS) was used to authenticate the transaction.
|
Set to true if the 3D Secure authentication process was initiated for the transaction. The 3DS process is considered initiated when a check is performed to confirm issuer and cardholder enrolment, before asking for a challenge to be performed.
This is set to false if the 3DS process was not initiated and the transaction proceeded to authorisation.
|
Set to true if a step-up authentication was initiated, for example, the customer was asked to enter a password or use a form of biometric authentication.
If attempted is set to false, then challenged should be omitted. If attempted is set to true, and a challenge was not presented to the customer, then this field should be set to false.
In 3DS2, if a customer achieves a frictionless authentication this should also be set to false.
|
Set to true if the customer was successfully authenticated using 3D Secure (either through frictionless authentication or a challenge) and the 3DS process was completed successfully.
This field should be set to false if the customer was unable to authenticate themselves during the challenge process, if an error occured, or frictionless authentication was not successful.
This field should be omitted if attempted is set to false.
|
The time at which the customer was directed to 3DS.
A Unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
The time at which the customer returned from 3DS.
A Unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
Whether the customer is believed to have abandoned 3DS.
|
The version of 3DS that was used to authenticate the customer.
|
Whether the liability of the transaction resulting in a chargeback has moved from the merchant to the card issuer.
(See Liability Shift.)
|
The Electronic Commerce Indicator (ECI) value returned by the issuer after authentication was attempted.
|
The Transaction Status (transStatus) value received in the final authentication message. The final message type (PaRes, ARes, CRes) will vary depending on the version of 3DS and whether the customer was challenged.
|
Provides information on why the transStatus field has the specified value. Will only be provided by the issuer when the transStatus value is N, U or R. (3DS 2 only)
|
Identifies the type of message from which the transStatus value was received. (3DS 2 only)
|
If the transStatus value is U the accompanying invalid request code (iReqCode) should be provided to further explain the reason authentication could not be performed. (3DS 1 only)
|
|
the decline code from the payment gateway, if applicable.
|
A code returned from the payment gateway after an attempt to charge, if applicable.
|
The result of AVS checks. You must have at least one of street or postal code.
Any of the following:
Show definition
|
Compatible with common PSP codes
|
Compatible with common PSP codes
|
|
The result of CVV verification from the issuer, compatible with common PSP codes.
|
The billing descriptor - usually including your company name - to be shown on the payment card statement.
|
|
|
The merchant ID that the transaction was processed under. The merchant ID is used to identify you to your acquirer and the financial institutions that will be involved in processing the transaction.
|
The 23-digit reference number assigned to the transaction by the acquirer. Often abbreviated to ARN. Not available until the transaction has settled.
Pattern: ^[0-9]{23}$
|
The acquirer is a financial institution with whom the merchant has a bank account.
|
The BIN (Bank Identification Number) of the acquirer.
|
The three letter country code of the country in which your acquirer will settle the payment.
|
The Merchant Advice Code (MAC) can be returned by Mastercard issuers for both approved and refused payments. If present, the code contains information about why the payment failed, whether it can be retried, the recommended duration after which it should be retried and indicators of the card used being a virtual card.
Show options
One of the following:
-
01 - New account information available
-
02 - Cannot approve at this time, try again later
-
03 - Do not try again
-
04 - Token not supported
-
21 - Stop recurring payment
-
24 - Retry after 1 hour
-
25 - Retry after 24 hours
-
26 - Retry after 2 days
-
27 - Retry after 4 days
-
28 - Retry after 6 days
-
29 - Retry after 8 days
-
30 - Retry after 10 days
-
40 - Consumer non-reloadable prepaid card
-
41 - Consumer single-use virtual card number
|
Custom data that is relevant to your domain. This can be any json object.
Please include any details that you think are relevant to fraud that our
schema does not capture.
|
Whether this transaction is associated with a chargeback.
|
email
string
optional
deprecated
The e-mail that the customer wants to be notified about this
transaction on.
|
debit
integer
optional
deprecated
Deprecated in favour of amount. The debit amount of the
transaction in the lowest denomination of the currency.
|
credit
integer
optional
deprecated
Deprected in favour of amount. The credit amount of the
transaction in the lowest denomination of the currency.
|
|
One or more attempts to charge a payment method to pay or be refunded for an order. Mutually exclusive with transaction.
|
The currency of the amount of this transaction, as an ISO 4217 currency code.
Pattern: ^[a-zA-Z]{3}$
|
A unique identifier for the transaction.
Required when sending a transaction before talking to the PSP, because the alternative gatewayReference cannot be known. If telling Ravelin about the transaction after processing it (as with a refund, for example) transactionId can be omitted in place of gateway and gatewayReference.
|
The time that the transaction is being attempted.
A Unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
|
|
The type of transaction interacting with the payment method.
auth: An auth transaction is used to reserve funds on the customer's card without yet deducting it. Useful to verify whether the customer has sufficient funds in their account and reserving a limit when the final order price cannot be known. Sometimes known as a pre-auth.capture: A capture transaction is used to immediately deduct authorised funds (up to the amount auth'd) from a customer's card.auth_capture: A simultaneous combination of auth and capture in one transaction, for when there is no need to separately auth then capture. Typical with straightforward "buy now"-style checkout.refund: A refund transaction credits a customer's payment method. If you do not know the payment method ID you are refunding to, but do know the original transaction, see Associating refunds with payment methods.void: A void transaction is the explicit discarding of authorization of funds.use, redeem: Deprecated. See voucherRedemption on /v2/chargeback or /v2/paymentmethod/voucher.
One of:
preauth, auth, capture, auth_capture, void, refund, redeem, or use.
|
The gateway responsible for processing the transaction. Used to link to chargebacks. Usually only available after attempting the payment.
|
The reference given to this transaction by the processing gateway. Used to link to chargebacks. Usually only available after attempting the payment. Each transaction should have a unique gateway reference.
|
Whether the transaction successfully completed with no error.
|
Details on how 3D Secure (3DS) was used to authenticate the transaction.
|
Set to true if the 3D Secure authentication process was initiated for the transaction. The 3DS process is considered initiated when a check is performed to confirm issuer and cardholder enrolment, before asking for a challenge to be performed.
This is set to false if the 3DS process was not initiated and the transaction proceeded to authorisation.
|
Set to true if a step-up authentication was initiated, for example, the customer was asked to enter a password or use a form of biometric authentication.
If attempted is set to false, then challenged should be omitted. If attempted is set to true, and a challenge was not presented to the customer, then this field should be set to false.
In 3DS2, if a customer achieves a frictionless authentication this should also be set to false.
|
Set to true if the customer was successfully authenticated using 3D Secure (either through frictionless authentication or a challenge) and the 3DS process was completed successfully.
This field should be set to false if the customer was unable to authenticate themselves during the challenge process, if an error occured, or frictionless authentication was not successful.
This field should be omitted if attempted is set to false.
|
The time at which the customer was directed to 3DS.
A Unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
The time at which the customer returned from 3DS.
A Unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
Whether the customer is believed to have abandoned 3DS.
|
The version of 3DS that was used to authenticate the customer.
|
Whether the liability of the transaction resulting in a chargeback has moved from the merchant to the card issuer.
(See Liability Shift.)
|
The Electronic Commerce Indicator (ECI) value returned by the issuer after authentication was attempted.
|
The Transaction Status (transStatus) value received in the final authentication message. The final message type (PaRes, ARes, CRes) will vary depending on the version of 3DS and whether the customer was challenged.
|
Provides information on why the transStatus field has the specified value. Will only be provided by the issuer when the transStatus value is N, U or R. (3DS 2 only)
|
Identifies the type of message from which the transStatus value was received. (3DS 2 only)
|
If the transStatus value is U the accompanying invalid request code (iReqCode) should be provided to further explain the reason authentication could not be performed. (3DS 1 only)
|
|
the decline code from the payment gateway, if applicable.
|
A code returned from the payment gateway after an attempt to charge, if applicable.
|
The result of AVS checks. You must have at least one of street or postal code.
Any of the following:
Show definition
|
Compatible with common PSP codes
|
Compatible with common PSP codes
|
|
The result of CVV verification from the issuer, compatible with common PSP codes.
|
The billing descriptor - usually including your company name - to be shown on the payment card statement.
|
|
|
The merchant ID that the transaction was processed under. The merchant ID is used to identify you to your acquirer and the financial institutions that will be involved in processing the transaction.
|
The 23-digit reference number assigned to the transaction by the acquirer. Often abbreviated to ARN. Not available until the transaction has settled.
Pattern: ^[0-9]{23}$
|
The acquirer is a financial institution with whom the merchant has a bank account.
|
The BIN (Bank Identification Number) of the acquirer.
|
The three letter country code of the country in which your acquirer will settle the payment.
|
The Merchant Advice Code (MAC) can be returned by Mastercard issuers for both approved and refused payments. If present, the code contains information about why the payment failed, whether it can be retried, the recommended duration after which it should be retried and indicators of the card used being a virtual card.
Show options
One of the following:
-
01 - New account information available
-
02 - Cannot approve at this time, try again later
-
03 - Do not try again
-
04 - Token not supported
-
21 - Stop recurring payment
-
24 - Retry after 1 hour
-
25 - Retry after 24 hours
-
26 - Retry after 2 days
-
27 - Retry after 4 days
-
28 - Retry after 6 days
-
29 - Retry after 8 days
-
30 - Retry after 10 days
-
40 - Consumer non-reloadable prepaid card
-
41 - Consumer single-use virtual card number
|
Custom data that is relevant to your domain. This can be any json object.
Please include any details that you think are relevant to fraud that our
schema does not capture.
|
Whether this transaction is associated with a chargeback.
|
email
string
optional
deprecated
The e-mail that the customer wants to be notified about this
transaction on.
|
debit
integer
optional
deprecated
Deprecated in favour of amount. The debit amount of the
transaction in the lowest denomination of the currency.
|
credit
integer
optional
deprecated
Deprected in favour of amount. The credit amount of the
transaction in the lowest denomination of the currency.
|
|