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).
|
An eventType should identify what event in your system triggered this API call.
Pattern: ^[a-zA-Z0-9][a-zA-Z0-9-_]*$
|
The ID of the customer navigating through the checkout process.
Mutually exclusive with customer.
|
The customer navigating through the checkout process. Mutually
exclusive with customerId.
|
The unique identifier of the customer. If your system allows anonymous
checkout then we recommend making this the customer's email address.
|
The time that the customer registered. If this value is unknown, you
can set it to 'now' - Ravelin will retain the earliest value you have
sent for this customer ID.
A unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
The email address of the customer.
|
The time at which the customer verified their email, usually by
following a link back to your website from an email you sent to
their address.
A unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
The full name of the customer. If you have the name split into parts,
consider familyName and givenName instead.
|
The surname/last name of the customer. If you do not have the name
split into parts, consider name instead.
|
The first/given names of the customer. If you do not have the name
split into parts, consider name instead.
|
The telephone number of the customer. Best in
E.164 format with an
international dialing code.
|
The time at which the customer verified their telephone number,
usually by confirming a code from an SMS you sent to the number.
A unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
The country the telephone number directs to. Note that the country is
not an adequate replacement for the international dialing code in the
Dominican Republic or Puerto Rico where multiple dialing codes are
used.
A ISO 3166-1 Alpha 3
or Alpha 2 country code.
|
The bcypted form of the password for this customer. By its nature, the bcrypt operation is slow. Consider using passwordHashed if this is too slow for you.
|
The SHA256 form of the password for this customer. This must be base64 encoded.
|
The plaintext password for the customer. We never store the raw password but for security we recommend using one of the hashing options instead of the plaintext option.
|
Set to true on events where the password has been changed, false or omit otherwise.
|
The tags to set or unset. Use the tag ID followed by true or false, depending on whether you want to set or unset the tag.
|
|
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.
|
|
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 username the customer would log in with.
|
gender
string
optional
deprecated
The gender of the customer.
|
The wallet contents of the customer, in the form of an object whose
keys are currencies and values the amount held in that currency, in
the currency's basic units.
|
banned
boolean
optional
deprecated
Whether the customer is banned in your systems.
|
The home country for this customer. Doesn't change when the customer is briefly abroad.
|
market
string
optional
deprecated
The logical region in which this customer exists.
Pattern: ^[0-9a-z-]*$
|
The logical city in which this customer exists.
Pattern: ^[0-9a-z-]*$
|
|
A temporary ID for a customer when the real account ID has yet to be
minted. This must eventually be sent in conjunction with a real customer
ID to migrate the data into the full customer account.
|
The order describing the goods or services the customer wants to, or has
attempted to buy.
|
A unique identifier for this order.
|
The time that the order was submitted by the customer. Used in reporting.
A unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
The mobile or web app that this order was submitted on. Used for
segmenting business analytics and creating app-specific risk profiles.
|
The name or brand of the app, used to segment orders. Use the name
that customer sees when installing and using the app, or the
website title. Shouldn't repeat the platform or domain.
|
One of:
ios, android, web, or mobile-web.
|
The domain from the URL of the web app, using the characters a-z0-9-..
Pattern: ^[a-z0-9-\.]+$
|
|
The stage of order in the purchase and delivery flow. Used in reporting.
One of the following:
|
|
Pending: The order is yet to be submitted for payment and processing, and you are yet to decide whether you will accept the order.
Show definition
|
|
|
The actor who caused the status change e.g. buyer, merchant.
|
|
|
Accepted: The customer has submitted the order and you intend to fulfill it. This stage is useful if you provide the goods and services before taking payment. If you take payment immediately, you can consider the order fulfilled.
Show definition
|
|
|
The actor who accepted the order.
|
|
|
Failed: Something went wrong, and the order can no longer be fulfilled.
Show definition
|
|
|
Description of why the order has failed.
One of:
payment_declined, seller_rejected, or system_error.
|
The actor who caused the status change e.g. buyer, merchant.
|
|
|
Cancelled: The order has been cancelled.
Show definition
|
|
|
Description of why the order has been cancelled.
One of:
buyer, seller, merchant, ravelin, or other_fraud_tool.
|
The actor who caused the status change e.g. buyer, merchant.
|
|
|
Fulfilled: The goods have been provided to the customer and payment has been successfully taken.
Show definition
|
|
|
The actor who caused the status change e.g. buyer, merchant.
|
|
|
Refunded: The order has been refunded.
Show definition
|
|
|
A description of why the order has been refunded.
One of:
returned, complaint, or ato.
|
The actor who caused the status change e.g. buyer, merchant.
|
|
The total price for this order, including delivery and taxes, in the currency's basic units. This price should always equal the sum of each items', tickets', and rooms' price times quantity.
|
The currency of the price for this order as an ISO 4217 currency code.
Pattern: ^[a-zA-Z]{3}$
|
The country the order should be attributed to for reporting and risk bucketing. Should reflect the country segmentation that you use for your reporting internally, whether that's by billing or shipping address, for example.
|
The country-group market the customer belongs to. E.g. 'southamerica', 'europe', 'emea'. Used for reporting and risk bucketing.
Pattern: ^[0-9a-z-]*$
|
The city that the customer belongs to. Used for reporting and risk bucketing.
Pattern: ^[0-9a-z-]*$
|
The highest level category that applies to this order as a whole, e.g.
the type of service provided. See item.category to describe
individual order items.
|
The delivery or drop-off location of the order. For taxis, can be the
requested drop-off location to begin, and updated to the actual
drop-off location once known.
|
|
|
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 pick-up location of the order. For taxis, can be the requested
pick-up location to begin, and updated to the actual pick-up location
once known.
|
|
|
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 line items of the order, describing what the customer is
purchasing. Including, but not limited to, products, services,
journeys, tips, taxes, and delivery fees.
|
Number of copies of this item that are present in the basket (set to 0 to remove).
|
A merchant specific identifier for an item or a service.
|
The name of the product or service that is being purchased.
|
|
|
|
|
The name of the brand that the item is from.
|
The name of the Universal Item Code.
|
The highest level category that this item is sold in.
|
A category that this item is sold in.
|
The scheduled time for the service described by this item.
A unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
If the item being purchased is a ticket for an event, associate the ticket and event information here.
|
The ticket information for this event.
|
A unique identifier for this ticket.
|
A short human-readable description of the type of ticket.
|
Timestamp at which this ticket is valid from.
A unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
Timestamp at which this ticket is valid until.
A unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
Whether this ticket is refundable or not.
|
|
The event the ticket is granting access to. This could be a access to an event, an attraction, or any other activity the customer is purchasing a ticket to attend.
|
A unique identifier for this event.
|
The category that best described the type of event.
One of:
adventure, attraction, conference, convention, culinary, business, family, festival, health, live show, music, party, social, sport, or other.
|
The location the event will take place.
|
|
|
|
|
|
|
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.
|
|
|
|
|
A short description of the event.
|
Timestamp at which event is scheduled to start. If the event is ongoing/recurring, you can use the ticket time here.
A unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
Timestamp at which event is scheduled to end. If the event is ongoing/recurring, you can use the ticket time here.
A unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
|
The individual who will be attending the event.
|
The named guest's given name.
|
The named guest's family name.
|
The named guest's full name.
|
Whether this guest is the individual who is purchasing the tickets.
|
|
|
If the item being purchased is a ticket for travel, associate the journey information here.
|
A unique identifier for the ticket
|
A human-readable text description of what the ticket provides
|
The person travelling with this ticket.
|
|
|
|
|
|
|
|
|
|
|
|
|
The type of document the passenger is traveling under
One of:
passport, driverslicense, or id.
|
The number that identifies the document
|
The 3 country code of the issuing country for the document
|
The Unix timestamp that the document was issued
|
The Unix timestamp that the document expires
|
|
|
The type of passenger this is
One of:
adult, child, infant, or senior.
|
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.
|
gender
string
optional
deprecated
|
|
The list of routes that this ticket grants the holder travel on.
|
The direction of travel along this route, e.g. 'outward' or 'return'.
|
This is an optional unique id to tie routes together. For example, You can tie a outbound and return route together with this. This way you can have multiple return tickets in one order and routes can be logically grouped together. This must be GLOBALLY UNIQUE
|
This is the list of travel legs taken by the passengers. It may contain any number of legs but must start at the first departure and end up at the final destination
|
The ID of the current leg. For flight tickets, flight number (e.g. 'BA101'). For bus tickets, bus number (e.g: 'A7')
|
Departure port code for the current leg. For flights: the 3 letter IATA airport code.
|
The location of the departure port for the current leg. For flights: the location of the airport.
|
|
|
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 city of departure for the current leg.
|
The ISO 3166 country code (2- or 3-letter) for the departure country of the current leg.
|
The departure time for the current leg.
A unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
Arrival port code for the current leg. For flights: the 3 letter IATA airport code.
|
The location of the arrival port for the current leg. For flights: the location of the airport.
|
|
|
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 city of arrival for the current leg.
|
The ISO 3166 country code (2- or 3-letter) for the arrival country of the current leg.
|
The arrival time for the current leg.
A unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
The name of the carrier/company conducting the current leg.
|
A publicly agreed code describing the carrier/company conducting the current leg. For Flights, this is the IATA 2 letter carrier code.
|
The type of transportation.
One of:
plane, train, bus, or ship.
|
Whether there are seat reservations on this leg.
|
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.
|
|
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.
|
|
If the passenger purchased travel insurance.
|
The class of travel this ticket grants access to.
One of:
business, economy, first, or standard.
|
The type of ticket this belongs to. This includes round trip, multi city, open return, etc
|
The time that this ticket can be used until.
A unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
The method in which a customer obtains their tickets. E-mail, pickup at station, physical mail, etc
|
The identifier for a loyalty card used on this order. If no loyalty card is used just omit this field
|
The identifier for a loyalty card used on this order. If no loyalty card is used just omit this field
|
|
If the item being purchased represents accommodation being booked, associate the trip information here.
|
Whether this booking is refundable or not.
|
Whether the payment is taken at the hotel during check-in.
|
The individual the booking is registered under (i.e the individual who will be checking in to the hotel). Either the current customer or another individual who the customer is booking the room on behalf of.
|
The booked guest's family name.
|
The booked guest's given name.
|
The booked guest's full name.
|
|
Timestamp at which any free cancellation period ends (unix time). Ignore if there is no free cancellation period.
|
Timestamp at which payment is due. Ignore if payment is taken immediately at booking.
A unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
Information on the hotel that the room is located in.
|
|
|
The location of the hotel.
|
|
|
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 star-rating awarded to this hotel. Use an 'offical' hotel classification value here, not a customer rating value.
|
|
Information on room being booked.
|
|
|
Timestamp at which guest check-in opens for the room.
A unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
Timestamp at which guest check-out closes for the room.
A unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
Maximum number of adult guests the room can accomodate.
|
|
|
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.
|
|
Shipping details of the order.
|
Number of expected days until the order is dispatched to the customer.
|
One of:
STANDARD, EXPRESS, NEXT_DAY, NOMINATED_DATE, SPECIFIC_TIME, CLICK_AND_COLLECT, ELECTRONIC_DELIVERY, or OTHER.
|
Type of destination for delivery.
One of:
HOME, BUSINESS, IN_STORE, COLLECTION_POINT, or OTHER.
|
Shipping company (e.g. DHL) or role of the supplier (e.g. seller) delivering the order.
|
|
Descriptive text relating to the contents or nature of the order being completed.
|
Contact e-mail for this order.
|
Contact phone number for this order. Best in E.164 format with an international dialing code.
|
Contact phone number's country
|
The unique identifier of the seller/counterparty in the transaction,
if not your business. E.g. The restaurant, driver ID, etc.
|
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.
|
Deprecated in favour of items.executionTime. Execution or pick-up time of the order.
|
Suppliers (e.g. restaurants, couriers or drivers) involved in this order.
|
The unique identifier of this supplier.
|
One of:
driver, courier, restaurant, shop, seller, or other.
|
|
Show definition
|
The order processing stage reached by this supplier.
One of:
accepted, in-progress, fulfilled, or cancelled.
|
The time when the supplier's status changed.
A unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
The reason provided by the supplier for this status change.
|
|
|
|
The value of a debt the supplier accrues to the platform as a result of this order, in
the currency's basic units. For example, a supplier may accrue a debt if they accept a
cash payment on behalf of the platform. The supplier's fee should not be deducted from the debt
- e.g. if the supplier's fee is £2.50 and the customer pays the supplier £10 in cash, the debt should be
1000
and the fee 250.
|
A voluntary tip paid by the customer to the supplier for the order, in
the currency's basic units. This is in addition to the supplier's fee.
|
|
|
|
|
A primary payment method to be charged in completing the checkout
process. Mutually exclusive with paymentMethodId and paymentMethods. One of the following:
One of the following:
|
|
card: A credit or debit card.
Show definition
|
Vault card payment method indicator.
One of:
card, creditcard, or debitcard.
|
A unique identifier for this payment, 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. 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 e-Wallet to which the customer associated the card.
One of:
applepay, googlepay, samsungpay, amazonpay, or visacheckout.
|
|
|
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 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.
|
|
|
paymentMethodCipher: 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, 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.
|
|
|
bankaccount: Bank Accounts.
Show definition
|
|
|
A unique identifier for this payment, 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 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.
|
|
|
paypal: PayPal payments.
Show definition
|
|
|
A unique identifier for this payment, 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 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.
|
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 indicator.
Only:
credit.
|
A unique identifier for this payment, 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 indicator.
Only:
invoice.
|
A unique identifier for this payment, 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
|
Vault card payment method indicator.
Only:
wallet.
|
A unique identifier for this payment, specific to this customer. Two
customers should not use the same paymentMethodId.
|
The name of the digital wallet scheme or electronic payment service.
|
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.
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. 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. 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.
|
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.
|
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 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).
|
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.
|
|
|
fromTransaction: 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
|
|
|
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.
|
|
|
|
|
directdebit: Direct Debits.
Show definition
|
|
|
A unique identifier for this payment, 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.
|
|
|
banktransfer: Bank Transfers.
Show definition
|
|
|
A unique identifier for this payment, 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.
|
|
|
Others - deprecated.
Show definition
|
Other method type indicator.
One of:
voucher, bitcoin, transfer, paysafe, cheque, or edenred.
|
A unique identifier for this payment, 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, specific to this customer. Two
customers should not use the same paymentMethodId.
|
False to indicate the payment method has been deactivated.
Only:
false.
|
|
One or more payment methods to be charged in completing the checkout process. Mutually exclusive with paymentMethod and paymentMethodId.
|
The ID of the primary payment method to be charged in completing the checkout process. Mutually exclusive with paymentMethod and paymentMethods.
|
An attempt to charge a payment method to pay or be refunded for an order. Mutually exclusive with transactions.
|
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 currency of the amount of this transaction, as an ISO 4217 currency code.
Pattern: ^[a-zA-Z]{3}$
|
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 straight-forward "buy now"-style checkout.refund: A refund transaction credit's 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 ID of the payment method to be charged in this transaction.
|
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 which was used to authenticate the customer. Either 1.0.2 or 2.1.0
|
Whether the liability of the transaction resulting in a chargeback has moved from the merchant to the card issuer.
(See Liability Shift.)
|
This field is deprecated, we do not use it in the Ravelin platform.
|
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 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 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.
|
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.
|
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 currency of the amount of this transaction, as an ISO 4217 currency code.
Pattern: ^[a-zA-Z]{3}$
|
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 straight-forward "buy now"-style checkout.refund: A refund transaction credit's 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 ID of the payment method to be charged in this transaction.
|
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 which was used to authenticate the customer. Either 1.0.2 or 2.1.0
|
Whether the liability of the transaction resulting in a chargeback has moved from the merchant to the card issuer.
(See Liability Shift.)
|
This field is deprecated, we do not use it in the Ravelin platform.
|
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 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 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.
|
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.
|
|
A voucher that is being used to pay for some of the order.
|
A unique identifier for the voucher usage. A transactionId for vouchers.
|
The string customers actually see in their app.
|
|
|
The time that the customer is utilising the voucher.
A unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
Whether the voucher has successfully been used by the customer.
|
The currency of the value of this voucher, as an ISO 4217 currency code.
Pattern: ^[a-zA-Z]{3}$
|
The time the after which the voucher can no longer be redeemed.
A unix timestamp as an
integer count of milliseconds, or nanoseconds since 1970-01-01T00:00
UTC.
|
The type of the voucher. If REFERRAL, also set the referredId so
Ravelin will create a network of who has invited who.
One of:
REFERRAL, REACTIVATION, or GENERAL.
|
The customerId of the customer who created this voucher.
|
|
|
Optional reason why the attempt was not successful.
One of:
EXPIRED, NOT_NEW_CUSTOMER, ALREADY_USED, ABUSER, SYSTEM_FAILURE, or MAX_ALLOWED_TIMES.
|
The source of why the voucher failed.
One of:
RAVELIN, or CLIENT.
|
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.
|
|
Any vouchers that are being used to pay for some of the order.
|
A unique identifier for the voucher usage. A transactionId for vouchers.
|
The string customers actually see in their app.
|
|
|
The time that the customer is utilising the voucher.
A unix timestamp preferably as an
integer count of milliseconds since 1970-01-01T00:00 UTC
(nanoseconds are also accepted).
|
Whether the voucher has successfully been used by the customer.
|
The currency of the value of this voucher, as an ISO 4217 currency code.
Pattern: ^[a-zA-Z]{3}$
|
The time the after which the voucher can no longer be redeemed.
A unix timestamp as an
integer count of milliseconds, or nanoseconds since 1970-01-01T00:00
UTC.
|
The type of the voucher. If REFERRAL, also set the referredId so
Ravelin will create a network of who has invited who.
One of:
REFERRAL, REACTIVATION, or GENERAL.
|
The customerId of the customer who created this voucher.
|
|
|
Optional reason why the attempt was not successful.
One of:
EXPIRED, NOT_NEW_CUSTOMER, ALREADY_USED, ABUSER, SYSTEM_FAILURE, or MAX_ALLOWED_TIMES.
|
The source of why the voucher failed.
One of:
RAVELIN, or CLIENT.
|
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 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.
|
Identifications are used by online customers to verify their real-world
identity. These forms of identification can be authenticated with
government authorities or authorised third-parties to confirm the
credentials are legitimate. Extra steps should be taken to confirm the
customer is the legitimate holder of these credentials.
|
A driving license permitting the holder to operate one or more types
of motorized vehicle.
|
The number unique to this piece of identification within the
jurisdiction country/state.
For privacy reasons, Ravelin recommends obfuscating the real number by
peppering and hashing it, using consistent one-way hashing function such
as SHA256.
|
|
|
The controlling state within the controlling country for this form of
identification. Not just the licence holder's home state. Omit where
the identification is controlled by a country-level authority.
|
The name of the identification holder.
|
|
A passport certifying the identity and nationality of its holder
primarily for the purpose of international travel.
|
The number unique to this piece of identification within the
jurisdiction country/state.
For privacy reasons, Ravelin recommends obfuscating the real number by
peppering and hashing it, using consistent one-way hashing function such
as SHA256.
|
|
|
The controlling state within the controlling country for this form of
identification. Not just the licence holder's home state. Omit where
the identification is controlled by a country-level authority.
|
The name of the identification holder.
|
|
|
|
The number unique to this piece of identification within the
jurisdiction country/state.
For privacy reasons, Ravelin recommends obfuscating the real number by
peppering and hashing it, using consistent one-way hashing function such
as SHA256.
|
|
|
The controlling state within the controlling country for this form of
identification. Not just the licence holder's home state. Omit where
the identification is controlled by a country-level authority.
|
The name of the identification holder.
|
|
|