Payment Method Saving is the first payment of a newly created payment series, during which the payment method is saved and the subsequent payment scenario is assigned to it.

For cards issued in EU, the 3DS authentication is required for payment method saving, if the mercant is located in Europe.

Payment Method Saving is compatible with the following payment scenarios and additional capabilities:

• One-Step Payment
• Two-Step Payment
• Zero-Amount Payment
• Full Refund
• Partial Refund
• Reversal
• Use of Travel Data (if saved as One-Click, Recurring (Automatic))
• Use of Dynamic Descriptor
• Use of Service Location details
• QCash
• MOTO
• SDWO Funding Payment
• SDWO Purchase Payment
• Taxes (if not a Zero-Amount Payment)
• AVS

Travel Data is a service that allows merchants and travel agencies to add relevant travel information to financial transactions; namely, information about airline addendum, lodging, car rentals, cruises, and ground transportation.

Here you can find the list of IATA carrier codes for Airline Addendum payments.

Use of Travel Data is compatible with the following payment scenarios and additional capabilities:

• One-Step Payment
• Two-Step Payment
• Zero-Amount Payment
• Full Refund
• Partial Refund
• Reversal
• Recuring (Automatic)
• One-Click
• Payment Method Saving
• Use of Dynamic Descriptor
• Use of Service Location details
• QCash
• MOTO
• Taxes
• AVS

Account Funding provides the option for one individual (merchant's client) to fund another individual's (also merchant's client) account. Account Funding is compatible only with One-Step Payment scenario.

Use of Account Funding details is compatible with the following payment scenarios and additional capabilities:

• One-Step Payment
• Use of Dynamic Descriptor
• Use of Service Location details
• Taxes
• AVS

Dynamic Descriptor provides a detailed description of transactions to help your customers recall their buying experience and avoid any disputes. In most cases, well-designed and informative dynamic descriptors eliminate any ambiguities or concerns about bank statements, as well as reduce chargebacks and identity fraud-related risks.

Use of Dynamic Descriptor is compatible with the following payment scenarios and additional capabilities:

• One-Step Payment
• Two-Step Payment
• Zero-Amount Payment
• Full Refund
• Partial Refund
• Reversal
• Recurring
• Recuring (Automatic)
• One-Click
• Payment Method Saving
• Use of Travel Data
• Use of Account Funding details
• Use of Service Location details
• QCash
• MOTO
• SDWO Funding Payment
• SDWO Purchase Payment
• Taxes
• AVS

Use of Service Location details indicates the place where the service is provided.

Here you can find the full list of Country Subdivision Codes for Service Location.

Use of Service Location details is compatible with the following payment scenarios and additional capabilities:

• One-Step Payment
• Two-Step Payment
• Zero-Amount Payment
• Full Refund
• Partial Refund
• Reversal
• Recurring
• Recuring (Automatic)
• One-Click
• Payment Method Saving
• Use of Travel Data
• Use of Account Funding details
• Use of Dynamic Descriptor
• QCash
• MOTO
• SDWO Funding Payment
• SDWO Purchase Payment
• Taxes
• AVS

QCash transactions are payments made in One-step and Two-step payment mode for cryptocurrency merchants.

QCash is compatible with the following payment scenarios and additional capabilities:

• One-Step Payment
• Two-Step Payment
• Full Refund
• Partial Refund
• Reversal
• Recurring
• Recuring (Automatic)
• One-Click
• Payment Method Saving
• Use of Travel Data
• Use of Dynamic Descriptor
• Use of Service Location details
• Taxes
• AVS

If your business receives orders via the Internet, you can still process card transactions by using the Mail Order/Telephone Order (MOTO) feature. MOTO allows you to process transactions without the cardholder and their card being present in your place of business (transactions without CVV).

MOTO is compatible with the following payment scenarios and additional capabilities:

• One-Step Payment
• Two-Step Payment
• Zero-Amount Payment
• Full Refund
• Partial Refund
• Reversal
• Use of Travel Data
• Use of Dynamic Descriptor
• Use of Service Location details
• Taxes
• AVS

SDWO (Staged Digital Wallet Operator) Funding Payment transactions are made from the cardholder’s card to their digital wallet.

SDWO Funding Payment is compatible with the following payment scenarios and additional capabilities:

• One-Step Payment
• Two-Step Payment
• Full Refund
• Partial Refund
• Reversal
• Recurring
• Recuring (Automatic)
• One-Click
• Payment Method Saving
• Use of Dynamic Descriptor
• Use of Service Location details
• Taxes
• AVS

SDWO (Staged Digital Wallet Operator) Purchase Payment transactions are made from the cardholder’s card to the merchant’s wallet for a specific purchase.

SDWO Funding Payment is compatible with the following payment scenarios and additional capabilities:

• One-Step Payment
• Two-Step Payment
• Full Refund
• Partial Refund
• Reversal
• Recurring
• Recuring (Automatic)
• One-Click
• Payment Method Saving
• Use of Dynamic Descriptor
• Use of Service Location details
• Taxes
• AVS

You can create and assign templates for taxes applicable to your products. To do this, you have to create a new tax by specifying its name and the percentage of the product price it will apply to. You can then apply this tax by specifying its properties in the tax field when creating a new product or updating an existing one.

Taxes are compatible with the following payment scenarios and additional capabilities:

• One-Step Payment
• Two-Step Payment
• Full Refund
• Partial Refund
• Reversal
• Recurring
• Recuring (Automatic)
• One-Click
• Payment Method Saving
• Use of Travel Data
• Use of Account Funding details
• Use of Dynamic Descriptor
• Use of Service Location details
• QCash
• MOTO
• SDWO Funding Payment
• SDWO Purchase Payment
• AVS

The Address Verification System (AVS) is a service that verifies whether the billing address matches the cardholder's address. AVS is a widely used fraud-prevention measure for Card Not Present (CNP) transactions, such as online payments or point-of-sale Mail Order/Telephone Order (MOTO) payments. AVS lets you check whether the shopper who is placing the order is the same person as the cardholder.

How does it work?

When a shopper pays for a transaction, you can collect their billing address details. Then, you send that data in the client object in the payment authorization request. If AVS is enabled, the system checks if and to what extent these billing address details match the information that the issuing bank has on file about the cardholder. The response to the payment request will contain DECTA AVS response code that is mapped to a raw AVS response code.

AVS result will appear in the webhook and/or GET request with a response code and description. Based on the AVS response, you can decide what to do with the payment: accept it, make an exception, or reverse a transaction.

AVS is supported for card payments made with Visa, Mastercard, and American Express. Card issuers in the United States, Canada, and the United Kingdom must support AVS verification requests.

Ask your manager whether you must use AVS! If the AVS permission is enabled for you and you do not provide billing address details in the order request, then the order will fail.

AVS is compatible with the following payment scenarios and additional capabilities:

• One-Step Payment
• Two-Step Payment
• Full Refund
• Partial Refund
• Reversal
• One-Click
• Payment Method Saving
• Use of Travel Data
• Use of Account Funding details
• Use of Dynamic Descriptor
• Use of Service Location details
• QCash
• MOTO
• SDWO Funding Payment
• SDWO Purchase Payment
• Taxes