TxShield

Overview

TxShield is a comprehensive, payment specific fraud and risk engine that allows for the structure and setup of fraud monitoring controls:

• per site;
• per merchant;
• or per payment method.

Further we can assign payment methods, nominate the available regions and add fraud settings. Our monitoring happens in real time and we can respond accordingly to breaches of program rules as they happen.

For any fraud management plan to be effective it is important to ensure that the appropriate reporting is being continually monitored and adjusted to stay ahead of potential threats.

Features

• Set transaction limit controls
• Set min and max transaction limits
• Allow/disallow repeat transactions
• Transaction velocity checking
• Geo IP Checking
• White listing, black listing, grey listing
• Reverse lookup testing (address, email and IP)
• Card bin lookup
• Receive card scheme alerts and respond
• Card registration for 3D Secure V1 and V2.0/2.1
• Chargeback listing by type
• Historical transaction checks - declines per account, card number etc
• Address verification
• Phone and SMS verification
• Dispute management and follow up
• Merchant ticket support management

Benefits

• Configurable to suit regional fraud requirements allowing greater flexibility for global merchants
• Added peace of mind for merchants and consumers

Transaction Types

TxShield can process different types of transactions.

• Payment transactions are instant and require a Visa and/or Mastercard to make the payment.
• Preauth transactions are used to authorise a transaction without settling it. These transactions can be settled either manually or using a postback from the gateway side.
• Credit transactions are transactions in which funds are credited to a recipients credit card. They are not instant transactions.
• Void transactions.
• Refund transactions.
• Rebilling transactions.

The card_type/payby parameter and the corresponding payment fields sent, will change depending on the type of transaction. In some cases, depending on the gateway integration methods, the payment transactions that use Visa and Mastercard are treated as preauth transactions in TxShield.

Below listed are the integration methods available for payment. Contact support for integration details for other transactions.

Integration Methods

SOAP

SOAP is a server-to-server API used for payment methods that can be used without user interaction. It is not useful for any payment method that requires user interaction. This method is for specific use cases, it is recommended that developers make use of the TxHandler or hosted payment page.

For more information click the following link: Make Payment using SOAP

Single Transaction API (TxHandler)

The TxHandler is used to send single transactions through form post.

After the transaction, the user can be redirected to a user defined location and also the result of the transaction can be received as postback to a user defined script/page.

For more information click the following link: Make Payment using TxHandler.

Parameter Definitions

Responses

To Redirect Page and to Postback Url

The response from the server is an array. If the status has the value "OK" the transaction has been successfully processed.

The response array has the following structure:

No Redirect URL

In case of no redirect url, the response will be a json string of the above mentioned array. This will be useful if you are using CURL post instead of FORM post. The status field will have one of the following values:

OK
The transaction was successful.

PEND
The transaction is pending and there will be a follow-up message.

EXC
The transaction is declined. The response should include information about the reason or exception encountered.

PAYG_ERROR
This is a rare response, indicating a problem with communicating with the processor.

Sample Code

Sample form post (HTML)

Please note that the sid and hash value used in this sample will not work for actual testing. You will need to replace those values when testing.

<form action="http://{shield_url}/secure/txHandler.php" method="post">
    sid: <input type="text" name="sid" value="19"><br>
    tid: <input type="text" name="tid" value="5678">br>
        postback_url: <input type="text" name="postback_url" value="http://mysite.com/postback.php"><br>
    redirect_url: <input type="text" name="redirect_url" value="http://mysite.com/redirect.php"><br>
        timestamp: <input type="text" name="timestamp" value="1234568995265421"><br>
        hash: <input type="text" name="hash" value="08ff1b1b14a09acfd67560baae229c4e"><br>
    firstname: <input type="text" name="firstname" value="Jack"><br>
    lastname: <input type="text" name="lastname" value="Tester"><br>
    phone: <input type="text" name="phone" value="1234567"><br>
    email: <input type="text" name="email" value="test@example.com"><br>
    address: <input type="text" name="address" value="12 Test Lane"><br>
    suburb_city: <input type="text" name="suburb_city" value="TestCity"><br>
    state: <input type="text" name="state" value="CA-ON"><br>
    postcode: <input type="text" name="postcode" value="41010"><br>
    country: <input type="text" name="country" value="CA"><br>
    ship_firstname: <input type="text" name="ship_firstname" value="Julie"><br>
    ship_lastname: <input type="text" name="ship_lastname" value="Tester"><br>
    ship_address: <input type="text" name="ship_address" value="13 Test Lane"><br>
    ship_suburb_city: <input type="text" name="ship_suburb_city" value="TestCity"><br>
    ship_state: <input type="text" name="ship_state" value="CA-ON"><br>
    ship_postcode: <input type="text" name="ship_postcode" value="41010"><br>
    ship_country: <input type="text" name="ship_country" value="CA"><br>
    currency_code: <input type="text" name="currency" value="USD"><br>
    amount_shipping: <input type="text" name="amount_shipping" value="0.30"><br>
    amount_tax: <input type="text" name="amount_tax" value="0.00"><br>
    amount_coupon: <input type="text" name="amount_coupon" value="0.00"><br>
    card_type: <input type="text" name="card_type" value="visa"><br>
    card_no: <input type="text" name="card_no" value="41111111111111"><br>
    card_name: <input type="text" name="card_name" value="J Citizen"><br>
    card_cvv: <input type="text" name="card_cvv" value="123"><br>
    card_exp_month: <input type="text" name="card_exp_month" value="2014"><br>
    card_exp_year: <input type="text" name="card_exp_year" value="09"><br>
        tx_action: <input type="text" name="tx_action" value="FRAUDCHECK"><br>

    ref1: <input type="text" name="ref1" value=""><br>
    ref2: <input type="text" name="ref2" value=""><br>
    ref3: <input type="text" name="ref3" value=""><br>
    ref4: <input type="text" name="ref4" value=""><br>

    <table>
        <tr>
            <td>
            item_quantity: <input type="text" name="item_quantity[]" value="2">
            item_name: <input type="text" name="item_name[]" value="apple">
            item_no: <input type="text" name="item_no[]" value="a234">
            item_desc: <input type="text" name="item_desc[]" value="juicy green apple">
            item_amount_unit: <input type="text" name="item_amount_unit[]" value="0.59">
            </td>
        </tr>
        <tr>
            <td>
            item_quantity: <input type="text" name="item_quantity[]" value="1">
            item_name: <input type="text" name="item_name[]" value="pear">
            item_no: <input type="text" name="item_no[]" value="p567">
            item_desc: <input type="text" name="item_desc[]" value="fresh green pear">
            item_amount_unit: <input type="text" name="item_amount_unit[]" value="0.68">
            </td>
        </tr>
    </table>
    <input type="submit" value="Submit">
</form>

Secure Hosted Payment Page

Secure hosted payment page allows the merchant to use our facilities for their payment interface. Users are redirected to the secure hosted payment page from the merchant site, from there the user can choose their country, payment options and payment information.

Make Payment using Secure Hosted Payment Page

Rest API

Rest implementation of TxHandler allows you to send single transaction in xml, json or form url encoded format. It is not useful for any payment method that requires user interaction. Click REST API to see the rest api endpoints that are available.

Parameter Definitions

Gateway Emulators

There are gateway emulators that can be used without much changes to the code you already have.

Make Payment using Emulator

Fraud Integration/Check

3DS Integration

Integrate with TxShield for 3DS2 Authentication using our 3DS JS SDK. The following section and the 3DS DOM elements describe how to connect to the 3DS JS SDK and the options available.

We also have a demo payment page that shows how simple it is to integrate. Instructions for the demo payment page are in the 3DS Demo Payment Page section.

Implementation Guidelines

Example of the HTML form

<html>
    <body>
        <div class="your-page-content">
        <form id="billing-form" action="" method="post">
        </form>
        </div> <!-- End of page -->
        <script src="{txshield_3ds_url}/js/3d2integrator.v3.dist.js"></script>
        <script>
            let options = {
                showChallenge: true,
                showChallengePopup: true
            }
            let threeD2 = new ThreeDS2( "<insert-form-id-here>", "<txshield_3ds_sid>", "<amounttotal>","<hash>","<txshield_3ds_url>","<merchantreference>","this", "<options>");
            document.getElementById('billing-form').addEventListener('submit', function (e) {
                threeD2.do3D(fnresponse);
            })
        </script>
    </body>
</html>

Before you begin impementation you will need to have the following settings. They will be issued by txShield when you begin integration:

• txshield_3ds_url
• txshield_3ds_sid
• txshield_3ds_rcode

There are 7 steps to complete the 3DS JS SDK integration. Only the first 5 are mandatory if you are doing your Authorization (payment) processing through a different provider.

Most steps should see you only having to update your current payment page / check out page:

1. Add the 3DS JS SDK
2. Add data-threeds attributes
3. Initialize the 3DS JS SDK
4. call do3D()
5. handle authorisation result
6. Check the added input fields. only if Authorization Processing with TxShield
7. Submit the form for payment process. only if Authorization Processing with TxShield

1. Add the TxShield 3DS2 Javascript Library to the payment page.

Include JS SDK into a page <script src="{txshield_3ds_url}/js/3d2integrator.v3.dist.js"></script> * {txshield_3ds_url} is the TxShield server url that you are integrating with. This will be given to you at time of onboarding.

2. Add "data-threeds" attributes to form elements.

To the elements in the form that contain information relevant to 3DS Authentication, add the data-threeds attribute. The 3DS SDK will search for all elements marked with a data-threeds attribute. The value for the attribute tells the script what data this field contains. Example is below.

The pan, month and year elements are mandatory.

Add "data-threeds" Attributes to elements

<input name='creditCardNumber' id='creditCardNumber' data-threeds='pan'>
<input name='cardMonth' id='cardMonth' data-threeds='month'>
<input name='cardYear' id='cardYear' data-threeds='year'>

A full list of fields and the data-threeds tags is available in the 3DS Dom elements table below. The more fields, the higher the chance of a successful and accurate 3DS result.

3. Initialize the ThreeDS2 object.

Initialize the ThreeDS2 object.

let my3ds2 = new ThreeDS2('{formId}',
    '{txshield_3ds_sid}',
    '{amounttotal}',
    '{hash}',
    '{txshield_3ds_url}',
    '{merchantreference}',
    '{global window scope}',
    '{options}'
)

Intialize / Instantiate the 3DS SDK. This should be done on page load, as there are several network calls that are done. If this is done on page load, these network calls can be done in the background while the user is completing the payment form.

• formid: Is the id attribute of your <form> tag in your checkout page. This form should be your billing form that contains the data-threeds attributes detailed later. e.g. for <form id='billing-form'> the formid is 'billing-form' The form must have an id tag.

• txshield_3ds_sid: this will be given to you at time of onboarding.

• amounttotal: total amount to charge the customer in decimals. e.g. 10.00 12.34

• hash: md5 of txshield_3ds_sid, amount, rcode e.g. in php md5(txshield_3ds_sid.amount.rcode)

• txshield_3ds_url: is the TxShield server url that you are integrating too. This will be given to you at time of onboarding.

• merchantreference: merchants reference for this transaction. The reference here should be the same one for the payment transaction. for 3ds 1 this has a max length 20 characters. If the length is over 20 characters reference will be auotmatically trimmed.

• global window scope: this is the scope, for the window in which the billing form is in. For most integrations it will simply be this.

• options: options should be a java object that contains the different options available to configure the SDK.

3DS JS SDK Options

let options = {
    showChallenge: true,
    showChallengePopup: true,
    rebilling: true,
    rebillingData: {
        rebillingExpiry: "20231231",
        rebillingFrequency : 28
    }
}

3DS JS SDK Options

4. Call the do3D() method.

Call do3D()

my3ds2.do3D(function (data)) {
    //my callback
});

When the user has finished entering their card details and all other data-threeds tagged fields with data, you should start the 3DS work flow by calling the do3D() method. This would commonly be done when the user has submitted the payment form.

• callback function: Callback function that gets called when the authentication has been completed.

We would recommend calling the do3D() method after doing your initial data validation (making sure that the fields are filled out, and in the correct format etc.) This should avoid extra 3ds transactions and costs by sending empty fields.

5. Handle 3DS Result

In step 4, a callback function was provided to do3D(). When Authentication is completed, the callback function will be called.

Authentication is considered complete when the user has ended their interaction with the 3DS servers. Refer to the 3DS Response section to learn more details about the returned response and what it means.

Once the callback has been called, you can now submit your payment form for payment processing.

If you are doing your payment processing with us, you do not have to do anything else with this data, other than decide if you want to continue based on the transStatus.

If you are doing your payment processing with another provider, you can use this callback to format the data for your provider.

6. Added Input Fields

If the above steps are done correctly, the DOM will have upto two new input fields created, threeDSecure and addinfo. If payment processing with us, these fields must exist, and must be included in the final form submission. Do not remove them.

Extra fields added to the form

<input class="threeDSecure" type="hidden" name="threeDSecure" value="">
<input class="addinfo" type="hidden" name="addinfo" value="" data-threeds="id">

Make sure that threeDSecure element is not empty before submitting the form for 'tx_action=FRAUDCHECK'

7. Submit the form

Include the threeDSecure parameter in the final form submission. See the example on the right hand section.

3DS Response

The following covers the 3DS response fields and their values / meanings. There is also a translation of the TxShield response to 3DS1 naming conventions, as the TxShield response matches 3DS2 naming conventions.

Response Object

Json Response

{
    "threeDSIntegratorOid": "12345",
    "threeDSRequestorOrderID": "9566261c-a4b3-4e40-ac7b-6145e8096e71",
    "threeDSRequestorData": "eyJtZXJjaGFudF9yZWYiOiJNZXJjaFJlZjE2MjI3NjQ1NzI1ODkifQ==",
    "threeDSRequestorID": "123MCTMyMidHere1235678",
    "threeDSServerTransID": "68d3fda2-e997-4772-b211-fd2073524278",
    "acsTransID": "61e1585c-3ab4-4bab-adb9-d72d07a1b1f7",
    "dsTransID": "74E3ECFA-86D1-4561-ACC1-32F532144824",
    "transStatus": "Y",
    "transStatusReason": "",
    "authenticationValue": "AAUBASOWNkVIc2RRBJY2AAAAAAA=",
    "authenticationAlgorithm": "",
    "eci": "05",
    "version": "2.1.0",
    "errCode": "4001",
    "errMsg": ""
}

An example response object is on the right.

TransStatus

The values in the transStatus field along with the eci field indicated whether a liability shift has occured. If the value is Y, U, A you can attempt the authorization (payment) transaction. If the value is N, C, R we recommend not attempting the authorization transaction, however it is at the merchants Discretion if they wish to proceed.

Only a status of Y guarantees a full liability shift.

A transStatus of C should only be returned by the 3DS SDk if challenges are turned off. This turns the 3DS SDK into a frictionless workflow. If you receieve a transStatus of C the frictionless transaction has not authenticated. The ACS server (the card issuer) requested the Challenge work flow, and in a forced frictionless scenario this means the Authentication has failed. You should not proceed to payment. The 3DS SDK returns the transStatus of C so that the merchant can keep statistics and track how many potential authentications failed because the ACS requested a challenge, and you may want to use that to inform your decision to turn challenges on later, or keep them turned off.

TransStatusReason

The values in the transStatusReason field can be mapped to these reasons. The full text should already be in the msg field, in the response data so you don't need to map this yourself.

TxShield (3DS2) fields to 3DS1 translation

3DS DOM elements

Below is a list of all DOM elements you can tag with data-threeds attributes so the SDK can pick it up:

3DS Demo Payment Page

The demo payment page files can be downloaded here.

Files

There are 2 files included:

1. 3ds2DemoPaymentPage.html: Is an example payment / check out page, giving an example of how to integrate with the TxShield 3DS JS SDK. It is not intended to be a live payment page as it has no validation on the users input, and exposes your rcode to anyone who uses the page, which you should not do.
2. md5.js: is a third party javascript file used to create the hash, which is used in the validation and authorization of your calls to the 3DS JS SDK.

Installation

These files are intended for you to copy into the same directory on your webserver and be able to run directly from there.

Configuration

Once on the webserver all you have to do is update the 3ds2DemoPaymentPage.html file with the configuration values that we will supply to you. The variables in the demo pament page are surrounded with {{ variable }} and both the name and {{}} should be replaced, as per below.

• {{txshield_3ds_url}} : this is the url of the server you will connnect to, to do your 3ds2 authorization. It needs to be updated in 2 places. If the url we provide is "https://myauthserver.com";

  <script src="{{txshield_3ds_url}}/js/3d2integrator.v3.dist.js"></script> should be updated to: <script src="https://myauthserver.com/js/3d2integrator.v3.dist.js"></script>

  let shieldUrl = '{{txshield_3ds_url}}'; should be updated to: let shieldUrl = 'https://myauthserver.com';

• {{txshield_3ds_sid}} : this is the sid we provide to you. This is the equivalent of a username. If we provide you a sid of 808

  let shield3dsSid = '{{txshield_3ds_sid}}' should be updated to: let shield3dsSid = '808'

• {{txshield_3ds_rcode}} : this is the rcode we provide to you. This is the equivalent of your password. In a production environment this should never be exposed to the public. If we provide you a rcode of '598950057acc2dd9df729a5ed4b9750a7c03bbec'

  let shield3dsRcode = '{{txshield_3ds_rcode}}'; should be updated to: let shield3dsRcode = '598950057acc2dd9df729a5ed4b9750a7c03bbec';

You should now be able to run the demo payment page file. For details of test cards please contact support and we will provide you with the details of test cards that can be used for your solution.

Fraud check API Integration

For fraud integrations only, where payment processing is not required. Transaction can be sent to {URL}/api/v1/index.php/{SID}/fraudcheck.

The URL, SID and RCODE will be provided during onboarding process. The RCODE will be used in the FraudCheck API to create the hash string.

Fraudcheck Submission

var json3D2data = $('form#billing-form .threeDSecure').val();
var settings = {
    "url": "{url}/api/v1/index.php/{sid}/fraudcheck",
    "method": "POST",
    "timeout": 0,
    "headers": {
    "Content-Type": "application/x-www-form-urlencoded",
    "data": {
        "timestamp": "",
        "tid": "",
        "card_type": "",
        "card_no": "",
        "card_exp_month": "",
        "card_exp_year": "",
        "card_name": "",
        "firstname": "",
        "lastname": "",
        "email": "”,
        "phone": "",
        "address": "",
        "suburb_city": "",
        "state": "",
        "country": "",
        "postcode": "",
        "shipping_address": "",
        "shipping_suburb_city": "",
        "shipping_state": "",
        "shipping_country": "",
        "shipping_postcode": "",
        "amount": "",
        "currency": "",
        "threeDSecure": json3D2data,
        "hash": "42aceec719591670d4491780d2187527"
    },
    “success”:function (response) {
        console.log(response);
    }
};
$.ajax(settings);

Parameters

Responses

200 Response

{
  "sid": 0,
  "status": "string"
  "parent_txid": 0,
  "txid": 0,
  "tx_action": "string",
  "amount": 0,
  "currency": "string",
  "tid": "string",
  "comment": "string",
  "error_info": "string",
  "vrfy": "string"
}

Responses

To Redirect Page and to Postback URL

The response from the server is an array. If the status has the value "OK" the transaction step has been successfully processed. The response array has the following structure:

No Redirect URL

In case of no redirect URL, the response will be a JSON string of the above mentioned array. This will be useful if you are using CURL post instead of FORM post.

The tx_action field will have one of the following values:

• PAYMENT

A PAYMENT is a transaction that is processed synchronously and the transaction's final funding status is known. The status will indicate if the transaction is successful or unsuccessful.

• PREAUTH

A PREAUTH is an asynchronous transactions where the final funding state of the transaction hasn't yet been determined. Once the transaction has been completed this will be followed with a second post-back with a SETTLEMENT message. Some payment methods will reserve the funds at this point in the transaction process.

• AUTH

The AUTH transaction is a variant of the PREAUTH action; In this state, the amount is not deducted from the card.

• CAPTURE

The CAPTURE transaction is a variant of the SETTLEMENT action; In this state, the amount is deducted from the card used in the AUTH transaction.

• SETTLEMENT

A SETTLEMENT is the second part of a PREAUTH transaction, indicating that we now know the final funding state of the transaction. The status will indicate if the transaction is successful or unsuccessful.

• REFUND

A REFUND transaction happens when a merchant returns the funds to the customer. The status will indicate if the transaction is successful or unsuccessful.

• CHARGEBACK

A CHARGEBACK transaction happens when a customer disputes the transaction and has initiated the dispute process for that payment option. The status will indicate if the transaction is successful or unsuccessful.

The status field will have one of the following values:

• OK

The transaction was successful.

• PEND

The transaction is pending and there will be a follow-up message.

• EXC

The transaction is declined. The response should include information about the reason or exception encountered.

• PAYG_ERROR

This is a rare response, indicating a problem with communicating with the processor.

Getting Payment Method Options

FeeAPI and RawFeeAPI

FeeAPI and RawFeeAPI provides a way to get a list of payment methods and information for a given sid. These request should only be used server-to-server as they use the rcode.

General Information

Interface Location

The Fee API located at: https://txprocess.uat.ipayoptions.com/soap/feeapi.php

The RawFeeAPI located at: https://txprocess.uat.ipayoptions.com/soap/rawfeeapi.php

It will only be accessible from your domain when data has been sent via HTTP POST towards it.

FeeAPI will give you the cart converted to the currency of the payment method.

FeeAPI and RawFeeAPI will both give you the list of payment methods and the fields. Fields section in the response will have the input requirement for sending the transaction to the gateway.

FeeAPI Parameter Definitions

RawFeeAPI Parameter Definitions

Response - FeeAPI

The FeeAPI will return a JSON response. If addfee option is 0, your Processing Fees will not be there.

[{
    "mxsid":"188",
    "payby":"visa",
    "title":"Visa",
    "display_title":"Test",
    "description":"\u00a0",
    "transfertime":null,
    "transferlimit":null,
    "currency_code":"USD",
    "currency_symbol":"$",
    "image":"https://txprocess.uat.ipayoptions.com/secure/dbfile.php?type=pmimg&id=1&nocache=575a36bb51db4",
    "fee":12.63,
    "cart": {
        "summary": {
            "quantity":"1",
            "amount_purchase":16.36,
            "amount_shipping":0,
            "amount_tax":0,
            "currency_code":"USD",
            "amount_shipping_posted":null,
            "amount_tax_posted":null,
            "amount_coupon_posted":null,
            "amount_coupon":0,
            "currency_symbol":"$",
            "fxrate":0.85846649
        },
        "items": [{
            "quantity":"1",
            "name":"Economy single",
            "item_no":"e1234",
            "item_desc":"Single Economy ticket LHR - ZAR",
            "amount_unit":3.73,
            "amount_unit_posted":"3.20"
        },
        {
            "name":"Processing Fees",
            "quantity":1,
            "amount_unit_posted":10.84,
            "amount_unit":12.63,
            "item_no":"",
            "item_desc":"Processing Fees"
        }]
    },
    "fields":
    {
        "card_name":
        {
            "description":"",
            "type":"text",
            "title":"Card Holder Name",
            "required":1
        },
        "card_no":
        {
            "description":"No spaces or dashes allowed",
            "type":"text",
            "title":"Card Number",
            "required":1,
            "pattern":"[0-9] { 13,19 }"
        },
        "card_cvv":
        {
            "description":"CVV",
            "type":"text",
            "title":"CVV",
            "required":1,
            "pattern":"[0-9]{3,4}"
        },
        "card_exp_month":
        {
            "description":"",
            "type":"select",
            "options":["01","02","03","04","05","06","07","08","09","10","11","12"],
            "title":"Card Expiry Month"
        },
        "card_exp_year":
        {
            "description":"",
            "type":"select",
            "options":[2016,2017,2018,2019,2020,2021,2022,2023,2024,2025,2026,2027],
            "title":"Card Expiry Year"
        }
    }
}]

Response - RawFeeAPI

The RawFeeAPI will return a JSON response.

[{
    "mxsid":"188",
    "payby":"visa",
    "title":"Visa",
    "display_title":"Test",
    "description":"\u00a0",
    "transfertime":null,
    "transferlimit":null,
    "currency_code":"USD",
    "currency_symbol":"$",
    "image":"https://txprocess.uat.ipayoptions.com/secure/dbfile.php?type=pmimg&id=1&nocache=575a4029d6950",
    "fee":{
        "exchange_src":"same",
        "rate":1,
        "commission_src":"same",
        "margin":0,
        "flatfee":10,
        "mdr":3
    },
    "fields":
    {
        "card_name":
    {
        "description":"Card holder name",
        "type":"text",
        "title":"Card Name",
        "required":1
    },
    "card_no":
    {
        "description":"No spaces or dashes allowed",
        "type":"text",
        "title":"Card Number",
        "required":1
    },
    "card_cvv":
    {
        "description":"Card CVV2",
        "type":"text",
        "title":"CVV2",
        "required":1},
        "card_exp_month":
        {
            "description":"2 digits",
            "type":"select",
            "options":["01","02","03","04","05","06","07","08","09","10","11","12"],
            "title":"Card Expiry Month"
        },
        "card_exp_year":
        {
            "description":"4 digits",
            "type":"select",
            "options":[2016,2017,2018,2019,2020,2021,2022],
            "title":"Card Expiry Year"
        }
    }
}]

Testing

Not all gateways provide a testing environment but we will be able to setup a test gateway for testing.

To test your integration, please contact support and you will be provided with a testing SID. Any transaction processed on the testing SID will only be checked syntactically and semantically by TxProcess UAT. This way you can test if you have sent sufficient and correct data.

The information given below is for testing using our test gateway only. No amount will be deducted from the account. Test responses are simulated based on the amount sent.

When performing credit card type transaction testing with your testing SID, the following card details can be used:

The following transaction amounts can be used to test different transaction results with your testing SID.

You will be able to view the results of your testing transactions in TxProcess UAT by searching for them on the Browse Transactions page with your testing SID as a search item.

Other documentation

Link to old documentation here.