Submitting Transactions
The payment gateway supports several credit card transaction types for transactions submitted by API.
You can develop the application in one of two ways:
- By yourself using the information provided in this document
- By using merchantPlus sample code available for free from our Developer Center.
Developer test accounts with API Login IDs and Transaction Keys are also available to test your integration methods to the Merchant Plus Payment Gateway.Please contact MerchantPlus Support at support@merchantplus.com to obtain a test login! https://gateway.merchantplus.com/
Minimum Requirements for Normal Transactions (FirstData or Tsys)
The following table represents the minimum fields required for submitting a credit card transaction request to the payment gateway using API The data fields are name/value pairs with the following syntax: x_name_of_field=value of field&.
| Field Name | Description |
|---|---|
| x_login | Value: The merchant’s unique Login ID Format: Up to 20 character Notes: The merchant API Login ID is provided in the Merchant Interface and must be stored securely. The Login ID and Transaction Key together provide the merchant the authentication required for access to the payment gateway. |
| x_tran_key | Value: The merchant’s unique Transaction Key Format: 16 character Notes: The merchant Transaction Key is provided in the Merchant Interface and must be stored securely. The API Login ID and Transaction Key together provide the merchant the authentication required for access to the payment gateway. |
| x_Method | Value: The Method of credit card transaction Format; CC , SVP Notes :If this field is not submitted or the value is blank, the payment gateway will generate an error "x_Method cannot be left blank". |
| x_type | Value: The type of credit card transaction Format; AUTH_CAPTURE (default), AUTH_ONLY, CREDIT, PRIOR_AUTH_CAPTURE, VOID ( for FirstData and Tsys transaction ) Notes: If the value submitted does not match a supported value, the transaction is rejected. If this field is not submitted or the value is blank, the payment gateway will generate an error "x_type cannot be left blank". |
| x_amount | Value: The amount of the transaction Format; Up to 15 digits (no dollar symbol). For example, 102 Notes: This is the total amount and must include tax, shipping, and any other charges. If this field is not submitted or the value is blank, the payment gateway will generate an error "x_amount cannot be left blank". |
| x_card_num | Value: The customer’s credit card number Format; Between 13 and 16 digits without spaces. Notes: This is sensitive cardholder information and must be stored securely and in accordance with the Payment Card Industry (PCI) Data Security Standard. If this field is not submitted or the value is blank, the payment gateway will generate an error "x_card_num cannot be left blank". |
| x_exp_date | Value: The customer’s credit card expiration date. Format; MMYY Notes: This is sensitive cardholder information and must be stored securely and in accordance with the Payment Card Industry (PCI) Data Security Standard. If this field is not submitted or the value is blank, the payment gateway will generate an error "x_exp_date cannot be left blank". |
| x_trans_id | Value: The payment gateway-assigned ID that links the current authorization request to the original authorization request. Format; Numeric Notes: This value applies only to partial authorization transactions, and is returned in the reply message from the original authorization request. If this field is not submitted or the value is blank, the payment gateway will generate an error "x_trans_id cannot be left blank".
|
| x_delim_data | Value: Indicates whether a delimited transaction response is required Format; TRUE, T, YES, Y Notes: A value of TRUE indicates a request for delimited response from the payment gateway. Since all AIM transactions are direct response, a value of TRUE is required. Submit this field for each transaction to be sure that transaction responses are returned in the correct format. See "Transaction Response," for more about delimited response. |
Credit Card Transaction Types
This section describes the credit card transaction types supported by the payment gateway and their specific field requirements. It’s a good idea to talk to your merchant about how their business plans to submit transaction so that you can properly integrate their payment gateway account to support their business processes.
Authorization and Capture
This is the most common type of credit card transaction and is the default payment gateway transaction type. The amount is sent for authorization, and if approved, is automatically submitted for settlement.
The unique field requirement for an Authorization and Capture transaction is: x_type=AUTH_CAPTURE
Authorization Only
This transaction type is sent for authorization only. The transaction will not be sent for settlement until the credit card transaction type Prior Authorization and Capture (see definition below) is submitted, or the transaction is submitted for capture manually in the Merchant Interface.
If action for the Authorization Only transaction is not taken on the payment gateway within 30 days, the authorization expires and is no longer available for capture. A new Authorization Only transaction would then have to be submitted to obtain a new authorization code.
The unique field requirement for an Authorization Only transaction is: x_type=AUTH_ONLY
Merchants can submit Authorization Only transactions if they want to verify the availability of funds on the customer’s credit card before finalizing the transaction. This transaction type can also be submitted if the merchant does not currently have an item in stock or wants to review orders before shipping goods.
Prior Authorization and Capture
This transaction type is used to complete an Authorization Only transaction that was successfully authorized through the payment gateway.
The payment gateway accepts this transaction type and initiates settlement if the following conditions are met:
The original Authorization Only transaction was submitted within the previous 30 days (Authorization Only transactions expire on the payment gateway after 30 days).
The transaction is submitted with the valid transaction ID (x_trans_id) of an original, successfully authorized, Authorization Only transaction.
- The original transaction is not yet captured, expired or error-ed.
The amount being requested for capture is less than or equal to the original authorized amount. Only a single Prior Authorization and Capture transaction can be submitted against an Authorization Only.
The unique field requirements for a Prior Authorization and Capture are: x_type=PRIOR_AUTH_CAPTURE,
x_trans_id=Transaction ID here For this transaction type, the amount field (x_amount) is required only if a Prior Authorization and Capture is submitted for an amount that is less than the amount of the original Authorization Only transaction. If no amount is submitted, the payment gateway will initiate settlement for the amount of the original authorized transaction.
Credit (Refund)
This transaction type is used to refund a customer for a transaction that was originally processed and successfully settled through the payment gateway.
The payment gateway accepts Credits if the following conditions are met:
The transaction is submitted with the valid transaction ID (x_trans_id) of an original, successfully settled transaction.
The amount being requested for refund is less than or equal to the original settled amount.
The sum of multiple Credit transactions submitted against the original transaction is less than or equal to the original settled amount.
At least the last four digits of the credit card number (x_card_num) used for the original, successfully settled transaction are submitted. An expiration date is not required.
The transaction is submitted within 120 days of the settlement date of the original transaction.
The unique field requirements for a Credit transaction are: x_type=CREDIT ,
x_trans_id=Transaction ID.
Void
This transaction type can be used to cancel either an original transaction that is not yet settled, or an entire order composed of more than one transactions. A Void prevents the transaction or the order from being sent for settlement. A Void can be submitted against any other transaction type.
The payment gateway accepts Voids if the following conditions are met: The original transaction is not already settled, expired or error-ed
The unique field requirements for a Void transaction are: x_type=VOID , x_trans_id=Transaction ID
Not all processors accept zero dollar amount.