Overview

The Genome gateway workflow is based on the type of Transaction made. The gateway supports 8 types of transaction requests:

• AUTH – (not currently available) - authorization allows freezing a certain amount on a card account for 7 days (depends on the acquirer side), until AUTH is settled or voided. AUTH will be automatically voided after 7 days (depends on the acquirer side) by Genome. The period during which AUTH remains active can be changed due to the card association's regulations.

• AUTH3D – 3D Secure authorization is available for the account that is configured to support 3D Secure. This transaction type will initiate the 3DS flow.

• SALE – (not currently available) - the basic function that allows collecting money directly from the cardholder's account. After the sale is executed successfully, it can only be refunded by the merchant or charged back by the issuing bank.

• SALE3D – the complex transaction includes 3D Secure 3DS authorization transaction and SALE transaction. It is available for the account that is configured to support 3D Secure. This transaction type will initiate the 3DS flow.

• REFUND – a request instructing the Genome gateway to refund a previously settled transaction. A settled transaction can be refunded in full or by several partial refunds, which total does not exceed the original amount (code 3022 is returned otherwise). This transaction is used to refund customers and is initiated following their request or the merchant's needs. Send the next refund only after the previous one has a final status (code 3005 is returned otherwise).

• VOID – the VOID transaction enables the Merchant to back out of an erroneous or problematic transaction before it is settled or credited. As the voided transaction is canceled before it is sent to the acquirer bank, it will not appear in the customer's CC statement, nor will the original transaction that was canceled.

• SETTLE – a request instructing the Genome gateway to settle a previously authorized transaction, i.e., a transfer of funds from the customer's bank account to the merchant's bank account. This transaction is always preceded by an AUTH transaction.

• CHECK – a request that is used to check the transaction status.

Other definitions:

• ECI - Electronic Commerce Indicators - the security level associated with an Internet purchase transaction. The gateway will return an ECI in the message, which the merchant can use to gauge risk associated with the transaction. The Genome gateway will process the ECI to the acquirer or its processor for inclusion in the authorization request message.

ECI VALUES

*There are two possibilities for this stage: the issuer bank offered the customer to enroll online and the customer declined, or the bank did not make the offer.

Transaction flow schema

Copy
START
  |
  |── AUTH ──┬── VOID
  |          |
  |          └── SETTLE ──┬── REFUND
  |                       |
  |                       └── CHECK
  |
  |── AUTH3D ──┬── VOID
  |            |
  |            └── SETTLE ──┬── REFUND
  |                         |
  |                         └── CHECK
  |
  |── SALE ─────┬── REFUND
  |             |
  |             └── CHECK
  |
  |── SALE3D ───┬── REFUND
                |
                └── CHECK

Rules summary

• VOID → only after AUTH / AUTH3D, before SETTLE

• SETTLE → only after successful AUTH / AUTH3D

• REFUND → only after SALE, SALE3D, or SETTLE

• CHECK → can be used at any time

Access to the Genome gateway API

Genome live and test host-to-host API can be reached via the following URLs. The same URL and credentials are used for test and live requests. Send the XTS currency for test requests.

The Genome gateway supports various transaction flow scenarios, but this document will focus only on the general recommended scenario, described below.

1. After selecting goods and services, the cardholder presses 'Buy' or an equivalent button and proceeds to a page where he can enter or modify delivery information and the payment method. Payment method information may offer various payment methods, like 'Pay by credit card' or a similar option. This option should not include card number, expiry date, CVV2/CVC2, or any other card-related sensitive information. Because of the security risks involved, the merchant system should avoid requesting and storing credit card information on the merchant server.

2. If the cardholder selects the 'Pay by credit card' option, a merchant system must prepare authorization request fields and redirect the cardholder to the 'Enter credit card information' page on the Genome gateway URL. Alternatively, the merchant system itself may present this page directly to the cardholder. This form shall contain all card entry fields and visible/hidden fields relating to the order and merchant as required by the authorization request format.

3. After receiving the filled-in form using an AUTH/AUTH3D request, the Genome gateway validates the request information. If the request fails validation, the gateway sends an error response back to the merchant system.

4. If the provided card number belongs to a card range with a defined cardholder authentication method (AUTH3D), the gateway calls the corresponding authentication module (3D Secure), which performs protocol-specific processing. If the cardholder authentication is unsuccessful, the Genome gateway returns an error message to the merchant system.

5. The Genome gateway sends an authorization request to the issuer bank. Upon receiving the authorization, the gateway prepares and sends a transaction response back to the merchant system. The transaction response contains no credit card information or contains the card number in blinded form only. Gateway sends response messages to the merchant system.

6. If authorization is successful, the response message will contain the reference number field, to be used by the merchant system so it can complete or reverse the obtained authorization without the credit card information.

7. After receiving the online transaction response, the merchant system starts delivery of ordered goods and/or services to the cardholder. At this point, the requested amount is blocked on the cardholder's account.

8. If a merchant would like to make the authentication and sale process using one transaction at once, they can choose the SALE/SALE3D request, which includes AUTH/AUTH3D and SALE transactions consistently.

9. When the merchant has delivered the goods and services to the cardholder, the merchant system sends a SETTLE request (depending on the chosen transaction flow) to complete the transaction directly to the Genome gateway using a reference number to refer to the authorization transaction with its corresponding credit card information.

10. The Genome gateway validates the incoming message and requests financial completion of the transaction from the bank. At this point, the transaction amount is debited from the cardholder account, and the merchant account is credited with the appropriate amount. The gateway sends a response back to the merchant system within the response document.

11. If the merchant is unable to fulfill the cardholder order or if the cardholder cancels the order at a stage allowed by the merchant, the merchant system must send a VOID request to cancel the pending transaction or a REFUND request for a completed transaction. The merchant system sends this message directly to the Genome gateway API.

12. The gateway validates the incoming message and cancels the pending transaction on the Genome gateway side or requests a refund for a completed transaction from the bank. This may involve transferring funds from the merchant account back to the cardholder account. The gateway sends a reply to the merchant system within the response document. At any step, the merchant can check the transaction status by sending a CHECK request to the Genome gateway API.

Integration flow

Please follow the following flow:

1. Sign in to https://my.genome.eu/ and provide the PCI DSS AoC certificate and the ASV scan (both no older than 1 year) in the “Merchants” section.

2. Provide the list of required transaction types for your business model to support@genome.eu.

3. Test all the transaction types for your business model with the XTS currency.

4. Provide the reference of test transactions to support@genome.eu to finish the test integration.

5. If test transactions are processed correctly, the Genome's integration team will activate your account.

6. Switch from XTS to your live currencies.

7. Test the production integration with all transaction types for your business model.

Host-to-host request formats

• JSON request: To use a JSON request type, the request header should contain "Content-Type: application/json." The request content should be transmitted as a JSON object.

Test mode

Be advised: you can use any credit card or the cards listed below, as long as you use XTS in the currency field. XTS is an ISO currency code reserved for use in testing. You can do test payments in the XTS currency even when your merchant account is already approved and LIVE.

In test mode (XTS), Genome does not contact the acquirer: every valid request returns an emulated success. 3D Secure and declines are not simulated. All field validations apply.

Test credit cards

Be advised: test credit cards support the XTS currency only.

AUTH transaction

This transaction type is not currently available.

Purpose: The interface is used to hold the transaction amount on the cardholder's account with full payment card data.

Request parameters:

Sample code of the AUTH request in the "application/json" format:

Copy
{
    "api_version": 1,
    "merchant_account": "Account_MP_TRX",
    "merchant_password": "password123",
    "transaction_unique_id": "auth_request",
    "transaction_type": "AUTH",
    "amount": 9.99,
    "currency": "EUR",
    "card_number": "4111111111111111",
    "card_exp_month": "05",
    "card_exp_year": "2030",
    "cvv": "111",
    "first_name": "John",
    "last_name": "Doe",
    "card_holder": "John Doe",
    "address": "123 Street name.",
    "city": "New York",
    "state": "NY",
    "zip": "12100",
    "country": "USA",
    "user_phone": "+12025550000",
    "user_email": "johndoe@test.com",
    "user_ip": "127.0.0.1",
    "callback_url": "https://merchant.com/callback",
    "cof_type": "CIT-initial"
}

Be advised: In most cases, the conditional parameters are required for acquirers.

Be advised: Support for this transaction type depends on the acquirer side. Please clarify the information before implementing this transaction type.

Response parameters:

Sample code of the AUTH response in the "application/json" format:

Copy
{
    "api_version": 1,
    "merchant_account": "Account_MP_TRX",
    "sessionid": "543e2136-d46c-4d7d-a3b3-075cf9adkl01",
    "transaction_unique_id": "auth_request",
    "token": "5524fa52-75d8-4c7a-84ec-039d3097ab6f",
    "reference": "ATFF0000000039FDAEEF",
    "timestamp": 1608001694,
    "authcode": "authcode_1544565466.22",
    "status": "success",
    "code": 0,
    "message": "Transaction processed successfully"
}

After the AUTH transaction has been processed, a merchant has to send the following transactions:

• SETTLE
• VOID
• CHECK

AUTH (by token) transaction

This transaction type is not currently available.

Purpose: The interface is used to hold the transaction amount on the card account using the card token.

Request parameters:

Sample code of the AUTH (by token) request in the "application/json" format:

Copy
{
    "api_version": 1,
    "merchant_account": "Account_MP_TRX",
    "merchant_password": "merchant_password",
    "transaction_unique_id": "auth_by_token_request",
    "transaction_type": "AUTH",
    "amount": 9.99,
    "currency": "EUR",
    "first_name": "John",
    "last_name": "Doe",
    "card_holder": "John Doe",
    "address": "123 Street name.",
    "city": "New York",
    "state": "NY",
    "zip": "12100",
    "country": "USA",
    "user_phone": "+12025550000",
    "user_email": "johndoe@test.com",
    "user_ip": "127.0.0.1",
    "callback_url": "https://merchant.com/callback",
    "token": "5524fa52-75d8-4c7a-84ec-039d3097ab6f",
    "cof_type": "CIT-initial"
}

Be advised: In most cases, the conditional parameters are required for acquirers.

Be advised: Support for this transaction type depends on the acquirer side. Please clarify the information before implementing this transaction type.

Response parameters:

Sample code of the AUTH (by token) response in the "application/json" format:

Copy
{
    "api_version": 1,
    "merchant_account": "Account_MP_TRX",
    "sessionid": "543e2136-d46c-4d7d-a3b3-075cf9af6dea",
    "transaction_unique_id": "auth_by_token_request",
    "token": "5524fa52-75d8-4c7a-84ec-039d3097ab6f",
    "reference": "ATFF0000000039FDA11F",
    "timestamp": 1618001694,
    "authcode": "authcode_1518565221.44",
    "status": "decline",
    "code": 3100,
    "message": "General bank decline"
}

After the AUTH (by token) transaction has been processed, a merchant, depending on business requirements, has the ability but is not forced to send the following transactions:

• SETTLE
• VOID
• CHECK

AUTH3D transaction

Purpose: The interface is used to hold the transaction amount on the cardholder's account with full payment card data, using the 3D Secure flow. A successful AUTH3D is settled with SETTLE or released with VOID.

Request parameters:

Sample code of the AUTH3D request in the "application/json" format:

Copy
{
    "api_version": 1,
    "merchant_account": "Account_MP_TRX",
    "merchant_password": "password123",
    "transaction_unique_id": "auth3d_request",
    "transaction_type": "AUTH3D",
    "amount": 10,
    "currency": "USD",
    "card_number": "5191330000004415",
    "card_exp_month": "05",
    "card_exp_year": "2030",
    "cvv": "121",
    "first_name": "John",
    "last_name": "Doe",
    "card_holder": "John Doe",
    "address": "123 Street name.",
    "city": "New York",
    "state": "NY",
    "zip": "12100",
    "country": "USA",
    "user_phone": "+12025550000",
    "user_email": "johndoe@test.com",
    "user_ip": "127.0.0.1",
    "callback_url": "https://merchant.com/callback",
    "redirect_url": "https://merchant.com/redirect",
    "descriptor_merchant": "MyShop.com",
    "cof_type": "CIT-initial"
}

Be advised: In most cases, the conditional parameters are required for acquirers.

Be advised: No callback is sent for AUTH3D - use CHECK for the final status.

Be advised: Support for this transaction type depends on the acquirer's side. Please clarify the information before implementing this transaction type.

Response parameters:

Sample code of the AUTH3D response in the "application/json" format:

Copy
{
    "api_version": 1,
    "merchant_account": "Account_MP_TRX",
    "sessionid": "543e2136-d46c-4d7d-a3b3-075cf9adkl21",
    "transaction_unique_id": "auth3d_request",
    "token": "5524fa52-75d8-4c7a-84ec-039d3097ab6g",
    "reference": "A3FF0000000039FDAEEF",
    "timestamp": 1638001694,
    "eci": 5,
    "acs_url": "https://acs.bank.com/authentication",
    "authcode": "",
    "status": "success",
    "code": 0,
    "message": "Transaction processed successfully"
}

After the AUTH3D transaction has been processed, a merchant, depending on business requirements, has the ability but is not required to send the following transactions:

• SETTLE
• VOID
• CHECK

SETTLE transaction

Purpose: The interface is used to settle a previously authorized transaction (using AUTH).

Request parameters:

Sample code of the SETTLE request in the "application/json" format:

Copy
{
    "api_version": 1,
    "merchant_account": "Account_MP_TRX",
    "merchant_password": "password123",
    "transaction_unique_id": "settle_request",
    "transaction_type": "SETTLE",
    "amount": 9.99,
    "currency": "EUR",
    "reference": "ATFF0000000039FDA11F",
    "callback_url": "https://merchant.com/callback"
}

Be advised: An authorization can be settled once (partial capture allowed, amount <= authorized amount). A second SETTLE, or a SETTLE after VOID, is rejected with code 3003.

Be advised: Support for this transaction type depends on the acquirer’s side. Please clarify the information before implementing this transaction type.

Response parameters:

Sample code of the SETTLE response in the "application/json" format:

Copy
{
    "api_version": 1,
    "merchant_account": "Account_MP_TRX",
    "sessionid": "543e2136-d46c-4d7d-a3b3-075cf9adkl21",
    "transaction_unique_id": "settle_request",
    "token": "5524fa52-75d8-4c7a-84ec-039d3097ab6f",
    "reference": "STFF0000000039FDAEGG",
    "timestamp": 1408001694,
    "authcode": "",
    "status": "success",
    "code": 0,
    "message": "Transaction processed successfully"
}

After the SETTLE transaction has been processed, a merchant, depending on business requirements, has the ability but is not required to send the following transactions:

• REFUND (use the SETTLE reference)
• CHECK

SALE3D transaction

Purpose: The interface is used to check the ability to follow the 3DS flow for the card. The ECI code will be returned to explain the reason (for example, in a negative case). In the positive case, the SALE request runs automatically on the Genome’s gateway side. The response to the SALE request will be transmitted to the merchant callback URL.

Request parameters:

Sample code of the SALE3D request in the "application/json" format:

Copy
{
    "api_version": 1,
    "merchant_account": "Account_MP_TRX",
    "merchant_password": "password123",
    "transaction_unique_id": "sale3d_request",
    "transaction_type": "SALE3D",
    "amount": 10,
    "currency": "USD",
    "card_number": "5191330000004415",
    "card_exp_month": "05",
    "card_exp_year": "2030",
    "cvv": "121",
    "first_name": "John",
    "last_name": "Doe",
    "card_holder": "John Doe",
    "address": "123 Street name.",
    "city": "New York",
    "state": "NY",
    "zip": "12100",
    "country": "USA",
    "user_phone": "+12025550000",
    "user_email": "johndoe@test.com",
    "user_ip": "127.0.0.1",
    "callback_url": "https://merchant.com/callback",
    "redirect_url": "https://merchant.com/redirect",
    "descriptor_merchant": "MyShop.com",
    "cof_type": "CIT-initial"
}

Be advised: In most cases, the conditional parameters are required for acquirers.

Be advised: Support for this transaction type depends on the acquirer’s side. Please clarify the information before implementing this transaction type.

Response parameters:

Sample code of the SALE3D response in the "application/json" format:

Copy
{
    "api_version": 1,
    "merchant_account": "Account_MP_TRX",
    "sessionid": "543e2136-d46c-4d7d-a3b3-075cf9adkl21",
    "transaction_unique_id": "sale3d_request",
    "token": "5524fa52-75d8-4c7a-84ec-039d3097ab6g",
    "reference": "S3FF0000000039FDAEGG",
    "timestamp": 1638001694,
    "eci": 5,
    "acs_url": "https://acs.bank.com/authentication",
    "authcode": "",
    "status": "success",
    "code": 0,
    "message": "Transaction processed successfully"
}

Callback

Callback is a final response for the SALE3D transaction regarding the status of the transaction. According to the SALE3D flow, Genome initiates the SALE transaction automatically and sends the response to the predefined merchant callback URL. The parameters of the callback fields are provided below:

Sample code of the callback request for SALE3D transaction in the "application/x-www-form-urlencoded" format:

Copy
token=5aaaa194-1d68-4ef8-a72f-009184ee03a6
&reference=PTFF00000000396580CF
&transaction_unique_id=payout_0716100000
&status=success
&code=0
&message=Transaction processed successfully
&checkSum=4804928393234a6cd05f177569147091d7138da25fc61d9ee5add357017239a6

A callback is received by a merchant when, in response, Genome gets the code - 200 and body text - OK. In other cases, the callback is not received, and Genome will try to send the callback data periodically. The number of attempts is limited.

Be advised that Genome can resend callbacks a few times for one transaction. It depends on the acquirer bank’s side.

Examples below describe different cases with callback data receiving:

After the SALE3D transaction has been processed, a merchant, depending on business requirements, has the ability to send the following transactions:

• REFUND
• CHECK

checkSum calculation

The checkSum calculation allows comparing the value of the checkSum in the callback request with own calculation.

PHP algorithm below shows the calculation logic of "checkSum":

Copy
<?php

// Example of the callback request to merchant, application/x-www-form-urlencoded format.
$callbackData = 'token=5aaaa194-1d68-4ef8-a72f-009184ee03a6&reference=PTFF00000000396580CF&transaction_unique_id=payout_0716100000&status=success&code=0&message=Transaction processed successfully&checkSum=4804928393234a6cd05f177569147091d7138da25fc61d9ee5add357017239a6';

// Example of the sorted parameters. Also, private key, provided by Genome is added in the end of the line.
$sortedData = 'code=0|message=Transaction processed successfully|reference=PTFF00000000396580CF|status=success|token=5aaaa194-1d68-4ef8-a72f-009184ee03a6|transaction_unique_id=payout_0716100000|your_private_key';

// Getting the result of checkSum calculation
$countedCheckSum = hash('sha256', $sortedData);

?>

If you need to calculate and compare the value of the checkSum callback, use the algorithm described below:

Please note that all the callback values are counted in the calculation of the checkSum parameter.

• exclude from the array checkSum field, then sort the array by key in alphabetical order, form a line on the principle: key1 = value1 | key2 = value2 | switchN = valueN | your_private_signature from the sorted array

Please note that the value of your_private_signature is your API password.You can later access it via the Merchants tab -> Technical details section inside my.genome.eu.

If fully translated, the callback shown in the example in the line we get is:

• code=0|message=Transaction processed successfully|reference=PTFF00000061B7146A8B|status=success|token=43d206b5-af88-4770-9d08-0c7eb17b000|transaction_unique_id=000453542|your_private_signature

• The next step is to calculate the hash for the obtained line by hash sha256, the result should match the line transferred in checkSum field. $countedCheckSum = hash('sha256','code=0|message=Transaction processed successfully|reference=PTFF00000061B7146A8B|status=success|token=43d206b5-af88-4770-9d08-0c7eb17b000|transaction_unique_id=000453542|your_private_signature');

• If the values coincide - the signature is valid.

SALE transaction

This transaction type is not currently available.

Purpose: The interface is used to collect money directly from the cardholder's account using full payment card data.

Request parameters:

Sample code of the SALE request in the "application/json" format:

Copy
{
    "api_version": 1,
    "merchant_account": "Account_MP_TRX",
    "merchant_password": "password123",
    "transaction_unique_id": "sale_request",
    "transaction_type": "SALE",
    "amount": 9.99,
    "currency": "EUR",
    "card_number": "4111111111111111",
    "card_exp_month": "09",
    "card_exp_year": "2030",
    "cvv": "121",
    "first_name": "John",
    "last_name": "Doe",
    "card_holder": "John Doe",
    "address": "123 Street name.",
    "city": "New York",
    "state": "NY",
    "zip": "12100",
    "country": "USA",
    "user_phone": "+12025550000",
    "user_email": "johndoe@test.com",
    "user_ip": "127.0.0.1",
    "callback_url": "https://merchant.com/callback",
    "cof_type": "CIT-initial"
}

Be advised: In most cases, the conditional parameters are required for acquirers.

Response parameters:

Sample code of the SALE response in the "application/json" format:

Copy
{
    "api_version": 1,
    "merchant_account": "Account_MP_TRX",
    "sessionid": "543e2136-d46c-4d7d-a3b3-075cf9adkl01",
    "transaction_unique_id": "sale_request",
    "token": "5524fa52-75d8-4c7a-84ec-039d3097ab6f",
    "reference": "SLFF0000000039FDAEAB",
    "timestamp": 1618001694,
    "authcode": "",
    "status": "success",
    "code": 0,
    "message": "Transaction processed successfully"
}

After the SALE transaction has been processed, a merchant, depending on business requirements, has the ability but is not required to send the following transactions:

• SALE by token
• REFUND
• CHECK

SALE (by token) transaction

This transaction type is not currently available.

Purpose: The interface is used to collect money directly from a cardholder’s account using the card token value.

Request parameters:

Sample code of the SALE (by token) request in the "application/json" format:

Copy
{
    "api_version": 1,
    "merchant_account": "Account_MP_TRX",
    "merchant_password": "password123",
    "transaction_unique_id": "sale_by_token_request",
    "transaction_type": "SALE",
    "amount": 9.99,
    "currency": "EUR",
    "first_name": "John",
    "last_name": "Doe",
    "card_holder": "John Doe",
    "address": "123 Street name.",
    "city": "New York",
    "state": "NY",
    "zip": "12100",
    "country": "USA",
    "user_phone": "+12025550000",
    "user_email": "johndoe@test.com",
    "user_ip": "127.0.0.1",
    "callback_url": "https://merchant.com/callback",
    "token": "5524fa52-75d8-4c7a-84ec-039d-97ab6f",
    "cof_type": "MIT"
}

Response parameters:

Sample code of the SALE (by token) response in the "application/json" format:

Copy
{
    "api_version": 1,
    "merchant_account": "Account_MP_TRX",
    "sessionid": "543e2136-d46c-4d7d-a3b3-075cf9adkl21",
    "transaction_unique_id": "sale_by_token_request",
    "token": "5524fa52-75d8-4c7a-84ec-039d3097ab6f",
    "reference": "SLFF0000000039FDAEGG",
    "timestamp": 1628001612,
    "authcode": "",
    "status": "success",
    "code": 0,
    "message": "Transaction processed successfully"
}

After the SALE (by token) transaction has been processed, a merchant, depending on business requirements has the ability but is not required to send the following transactions:

• REFUND
• CHECK

REFUND transaction

Purpose: The interface is used to refund a previously settled transaction.

Request parameters:

Sample code of the REFUND request in the "application/json" format:

Copy
{
    "api_version": 1,
    "merchant_account": "Account_MP_TRX",
    "merchant_password": "password123",
    "transaction_unique_id": "refund_request",
    "transaction_type": "REFUND",
    "amount": 9.99,
    "currency": "EUR",
    "reference": "SLFF0000000039FDAEAB",
    "callback_url": "https://merchant.com/callback"
}

Be advised: Refunds are possible for the SALE, SALE3D, and SETTLE references. Several partial refunds are possible up to the original amount (code 3022 is returned otherwise). The currency must equal the original currency (code 3015 is returned otherwise). Wait for the final status of a refund before sending the next one (code 3005 is returned otherwise). Your balance must cover the refund (code 3101 is returned otherwise).

Response parameters:

Sample code of the REFUND response in the "application/json" format:

Copy
{
    "api_version": 1,
    "merchant_account": "Account_MP_TRX",
    "sessionid": "543e2136-d46c-4d7d-a3b3-075cf9adkl21",
    "transaction_unique_id": "refund_request",
    "token": "5524fa52-75d8-4c7a-84ec-039d3097ab6f",
    "reference": "RFF0000000039FDAEGG",
    "timestamp": 1614001691,
    "authcode": "",
    "status": "success",
    "code": 0,
    "message": "Transaction processed successfully"
}

After the REFUND transaction has been processed, a merchant, depending on business requirements, has the ability but is not required to send the following transactions:

• CHECK

VOID transaction

Purpose: Interface is used to to back out of a transaction before it is settled or credited.

Request parameters:

Sample code of the VOID request in the "application/json" format:

Copy
{
    "api_version": 1,
    "merchant_account": "Account_MP_TRX",
    "merchant_password": "password123",
    "transaction_unique_id": "void_request",
    "transaction_type": "VOID",
    "reference": "ATFF0000000039FDAEEF",
    "callback_url": "https://merchant.com/callback"
}

Be advised: Only an AUTH or AUTH3D that has not been settled or voided can be voided (code 3004 otherwise). After the VOID, the authorization cannot be settled.

Be advised: Support for this transaction type depends on the acquirer’s side. Please clarify the information before implementing this transaction type.

Response parameters:

Sample code of the VOID response in the "application/json" format:

Copy
{
    "api_version": 1,
    "merchant_account": "Account_MP_TRX",
    "sessionid": "543e2136-d46c-4d7d-a3b3-075cf9adkl21",
    "transaction_unique_id": "void_request001",
    "token": "5524fa52-75d8-4c7a-84ec-039d3097ab6f",
    "reference": "VDFF0000000039FDAEGG",
    "timestamp": 1601001621,
    "authcode": "",
    "status": "success",
    "code": 0,
    "message": "Transaction processed successfully"
}

After the VOID transaction has been processed, a merchant, depending on business requirements, has the ability but is not required to send the following transactions:

• CHECK

CHECK transaction

Purpose: The interface should be used to check the transaction status.

Request parameters:

Sample code of the CHECK request in the "application/json" format:

Copy
{
    "api_version": 1,
    "merchant_account": "Account_MP_TRX",
    "merchant_password": "password123",
    "transaction_type": "CHECK",
    "reference": "ATFF00000000395AD690",
    "transaction_unique_id": "check_request"
}

transaction_unique_id or reference can be passed for the CHECK request.

If no transaction is found, code 3014 is returned.

Response parameters:

Sample code of the CHECK response in the "application/json" format:

Copy
{
    "api_version": 1,
    "merchant_account": "Account_MP_TRX",
    "sessionid": "5668fbfb-2d9c-492c-9f7c-11fb8ae9e3fc",
    "transactions": [
        {
            "reference": "ATFF00000000395AD690",
            "transaction_unique_id": "check_request",
            "transaction_type": "AUTH",
            "status": "SUCCESS",
            "code": 0,
            "message": "SUCCESS",
            "token": "5519225d-3460-433f-ad4e-62649d0bb909",
            "timestamp": 1529796980,
            "authcode": "111313"
        }
    ],
    "status": "success",
    "code": 0,
    "message": "Transaction processed successfully"
}

After the CHECK transaction has been processed, the merchant can send any transactions depending on the stage of an actual transaction flow process.

Custom parameters

Additional custom parameters (request):

Purpose: Custom parameters can also be sent via API. For more information, please contact support@genome.eu

Additional custom parameters (response/callback):

Purpose: Custom parameters can be added to the response. For activation, please send a query to support@genome.eu.

Validation exposition: MDN web docs