Additional Capabilities

Payment Method Saving

Description

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

Request Example

Cardaq-side Payment Method Saving

Step 1: Create a new request to POST /clients/.

{
    "email": "client27@email.com"
}

This function will return the ID of the newly created customer which then can be used for assigning payment methods to.

Step 2: Create a new request to POST /orders/. Note that the price value must be ≥0.01.

{
    "client": {
        "original_client": "xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
        "email": client27@email.com"
    },
    "products": [
        {
        "title": "Test product",
        "price": 1.00,
        }
    ],
    "currency": "EUR",
    "setup_future_use": "recurring",
    "force_save_method": true
    "recurring_number": "1" // conditional field for recurring scenario, may be required for some acquiring connections
}

The ID of the original_client should be included in the request to assign the saved payment method to. The desired Payment Saving Method scenario should always be provided within the order body via the parameter setup_future_use. Possible values for the parameter setup_future_use are one-click, automatic, and recurring. If force_save_method is set to be true, then the payment method will be saved without the customer's consent. The recurring_number parameter should be provided only if setup_future_use parameter has value recurring.

Step 3:

  1. Present to the customer one of the Gateway-hosted checkout options (Full Page or JS SDK), using the appropriate URL you received in the response to the previous step;
  2. For the Host2Host integration, the execution is done as described here.

Step 4 (conditional): Perform 3DS authentication (link).

Merchant-side Payment Method Saving

Step 1: Create a new request to POST /orders/. Note that the price value must be ≥0.01.

{
    "client": {
        "email": "client27@gmail.com",
        "send_to_email": false
    },
    "products": [
        {
        "title": "Test product",
        "price": 1.00,
        }
    ],
    "currency": "EUR",
    "setup_future_use": "recurring"
    "recurring_number": "1" // conditional field for recurring scenario, may be required for some acquiring connections
}

The desired Payment Saving Method scenario should always be provided within the order body via the parameter setup_future_use. Possible values for the parameter setup_future_use are one-click, automatic, and recurring. The recurring_number parameter should be provided only if setup_future_use parameter has value recurring.
The request body above includes only the mandatory parameters for the request type. In case optional parameters are needed, see API Reference.

Step 2: Minimal body request to POST payment api_do_url

{
    "cardholder_name": "Adam Smith",
    "card_number": "4242424242424242",
    "exp_month": 6,
    "exp_year": 23,
    "csc": "111",
    "saved_by_merchant": true,
    "ip_address": "198.51.100.42"
}

Step 3 (conditional): Perform 3DS authentication (link).


Use of Travel Data

Description

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

Request Example

Create a new request to POST /orders/. Note that the price value must be ≥0.01.
NB: If you provide travel packages, we strongly recommend you to send the first service provided in the order (for example, if the travel package contains a flight and a hotel booking, then you must send Airline Addendum data in the order).

{
    "client": {
        "email": "test@test.com"
    },
    "travel_data": {
        "airline_addendum": { //if airline_addendum is sent, other travel types cannot be sent
            "ticket_number": "123",
            "passenger_name": "Adam Smith",
            "customer_ref": "123",
            "n_legs": 1,
            "carrier_name": "Test Airways",
            "ticket_issue_date": "121221",
            "legs": [
                {
                    "departure_airport": "RIX",
                    "carrier_code": "3d",
                    "destination_airport": "VIE",
                    "departure_date": "01012022",
                    "service_class": "Y",
                    "trip_number": "QR945",
                }
            ]
        },
        "lodging": { //if lodging is sent, other travel types cannot be sent
            "booking_number": "test",
            "checkin_date": "01012023",
            "checkout_date": "03012023"
        },
        "car_rental": { //if car_rental is sent, other travel types cannot be sent
            "booking_number": "test",
            "pickup_date": "01012023",
            "return_date": "03012023"
        },
        "cruise": { //if cruise is sent, other travel types cannot be sent
            "booking_number": "test",
            "departure_date": "01012023",
            "return_date": "03012023"
        },
        "ground_transportation": { //if ground_transportation sent, other travel types cannot be sent
            "booking_number": "test",
            "departure_date": "01012023",
            "return_date": "03012023"
        },
        "language": "en",
        "currency": "EUR",
        "products": [
            {
                "price": 0.01,
                "title": "Test Product"
            }
        ]
    }
}

The request body above includes only the mandatory parameters for the request type. In case optional parameters are needed, see API Reference.


Use of Account Funding details

Description

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

Request Example

Create a new request to POST /orders/. Note that the price value must be ≥0.01. NB: We advise to send client information in each AFT order request.

{
    "client": {
        "email": "test@gmail.com",
        "first_name": "John", // mandatory field for VISA AFT payments
        "last_name": "Smith", // mandatory field for VISA AFT payments
        "address": "1 High St, Capitol Heights, MD 20700", // mandatory field for VISA AFT payments
        "country": "US", // mandatory field for VISA AFT payments
        "state": "DC", // conditional field for VISA AFT payments: mandatory only for Canada and USA issuers
        "city": "Washington" // mandatory field for VISA AFT payments
    },
    "recipient_client": { // this object and all its fields are mandatory for all AFT payments
        "first_name": "John",
        "last_name": "Doe",
        "birth_date": "1996-09-11",
        "city": "Riga",
        "account_type": "02",
        "account_number": "XXXXX",
        "recipient_address": "Dzirnavu 101-1, Riga, LV1010" // mandatory field for VISA AFT payments
        "country": "LV",
        "same_as_client": false // if value is True, then Gate indicates that the recipient client information is the same as the client information. Note that this parameter is informative and does not copy the client data
    },
    "products": [
        {
            "price": 0.01,
            "title": "test",
            "description": "test description",
            "quantity": 1
        }
    ]
}

The request body above includes only the mandatory parameters for the request type. In case optional parameters are needed, see API Reference.


Use of Dynamic Descriptor

Description

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

Request Example

Create a new request to POST /orders/. Note that the price value must be ≥0.01.

{
    "client": {
        "email": "test@test.com"
    },
    "dynamic_descriptor": "test",
    "products": [
        {
            "title": "Test product",
            "price": 1.00
        }
    ]
}

The request body above includes only the mandatory parameters for the request type. In case optional parameters are needed, see API Reference.


Use of Service Location details

Description

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

Request Example

Create a new request to POST /orders/. Note that the price value must be ≥0.01.

{
    "client": {
        "email": "test@test.com"
    },
    "service_location": {
        "city": "London",
        "region": "ENG",
        "country": "GB",
        "zip_code": "W2 1HS"
    },
    "products": [
        {
            "price": 1.00,
            "title": "Title"
        }
    ]
}

The request body above includes only the mandatory parameters for the request type. In case optional parameters are needed, see API Reference.


QCash

Description

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

Request Example

Request examples for QCash payments are identical to One-step and Two-step payments. The only difference is in the terminal assigned but the order request bodies are the same.


MOTO

Description

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

Request Example

Create a new request to POST /orders/. Note that the price value must be ≥0.01.

{
    "client": {
        "email": "test@test.com"
    },
    "is_moto": true,
    "products": [
        {
            "price": 0.01,
            "title": "Title"
        }
    ]
}

The request body above includes only the mandatory parameters for the request type. In case optional parameters are needed, see API Reference.


SDWO Funding Payment

Description

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

Request Example

Create a new request to POST /orders/. Note that the price value must be ≥0.01.

{
    "client": {
        "email": "test@test.com"
    },
    "products": [
        {
            "price": 0.01,
            "title": "Title"
        }
    ]
}

The request body above includes only the mandatory parameters for the request type. In case optional parameters are needed, see API Reference.


SDWO Purchase Payment

Description

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

Request Example

Create a new request to POST /orders/. Note that the price value must be ≥0.01.

{
    "client": {
        "email": "test@test.com"
    },
    "sdwo_merchant_id": "XXXXX",
    "products": [
        {
            "price": 0.01,
            "title": "Title"
        }
    ]
}

The request body above includes only the mandatory parameters for the request type. In case optional parameters are needed, see API Reference.


Taxes

Description

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

Request Example

Create a new request to POST /taxes/.

{
    "name": "example",
    "percent": 10
}

The request body above includes only the mandatory parameters for the request type. In case optional parameters are needed, see API Reference.


Address Verification System

Description

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 Cardaq 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
  • 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
Custom AVS

When using Custom AVS, Gateway will ALWAYS perform AVS, even if the card is not issued in US/CA/UK and 3DS would also be applied. As a result, Custom AVS is used as either (a) the only security layer or (b) an additional security layer against potentially fraudulent transactions when necessary. The AVS check during payment authorization does not affect the authorization speed or result, thus the solution would not negatively impact the payment process in any way.

Request Example

In order to perform AVS, you have to set up your payment authorization requests to include billing address details.
Create a new request to POST /orders/. It is mandatory to send address and zip_code parameters. Note that the price value must be ≥0.01.

{
    "client": {
        "email": "test@test.com",
        "address": "1 High St, Capitol Heights",
        "zip_code": "MD 20700"
    },
    "products": [
        {
        "price": 0.01,
        "quantity": 1,
        "title": "Test product"
        }
    ]
}

The request body above includes only the mandatory parameters for the request type. In case optional parameters are needed, see API Reference.

Response example and avs_status descriptions can be found here.

Request Example for Custom AVS

In order to perform Custom AVS, you have to set up your payment authorization requests to include billing address details and send the avs parameter as true in the payment api_do_url request.

Step 1: Create a new request to POST /orders/. It is mandatory to send address and zip_code parameters. Note that the price value must be ≥0.01.

{
    "client": {
        "email": "test@test.com",
        "address": "1 High St, Capitol Heights",
        "zip_code": "MD 20700"
    },
    "products": [
        {
        "price": 0.01,
        "quantity": 1,
        "title": "Test product"
        }
    ]
}

The request body above includes only the mandatory parameters for the request type. In case optional parameters are needed, see API Reference.

Step 2: Mandatory body request to POST payment api_do_url:

{
    "cardholder_name": "Adam Smith",
    "card_number": "4242424242424242",
    "exp_month": 6,
    "exp_year": 23,
    "csc": "111",
    "avs": true
}

Response example and avs_status descriptions can be found here.