Payment Gateway API
The 360-One Payment Gateway enables merchants to run live credit card transactions by acting as a bridge between a point of sale system, and the 360-One payment network. It does this by receiving a name-pair value URL constructed by the merchant’s website, processing the request, then returning the proper result.
Contents
The implementation language is up to the developer, however several SDKs exist including Java, PHP, and C#.
Introduction
To effectively implement the 360-One Payment Gateway, basic API programming knowledge is required. While transactions are submitted as a URL, it is recommended to use a server-side scripting language to build the HTTP request.
System Architecture
The 360-One Payment Gateway is a state of the art system utilizing multiple director and server technology to efficiently route traffic and provide multiple layers of redundancy. The system is easily scalable and coded in a manner that accommodates a flexible development environment. 360-One maintains systems at two different sites that are always on, with traffic routed to both systems. If any service interruption is detected, traffic is automatically re-routed to the other site to maintain service levels and processing availability.
Technical Overview
The standard format of a Payment Gateway request is name-value pair, within the body of a standard HTTP POST. The response will return by default in name-value pair format, with the additional option of JSON.
The makeup of various requests are as follows. These are the bare minimum required to process an API request.
Example Sale request
- POST /mes–api/tridentApi HTTP/1.1
Content–Type: application/x–www–form–urlencoded
Cache–Control: no–cache
Pragma: no–cache
User–Agent: Java/1.7.0_21
Host: cert.merchante–solutions.com
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Content-Length: xxx
profile_id=94100099999900000001&profile_key=A7B8C9A7A7B8C9A7A7B8C9A7A7B8C9A7&transaction_type=D&card_number=4262369999996102&card_exp_date=0409&transaction_amount=15&cardholder_street_address=920&cardholder_zip=99212&invoice_number=12345&tax_amount=0.01
Example Sale response
A sale authorizes a transaction, then automatically captures it. This is beneficial in e-commerce situations for downloadable products, fee payments, or goods delivered immediately.
- transaction_id=XXXX&error_code=000&auth_response_text=Approval TXXXXX&avs_result=0&auth_code=TXXXXX
- Where profile_id is a 20-digit number and profile_key is a 32-character string both provided by the 360-One Certification Manager. The transaction_type, transaction_amount, card_number and card_exp_dateare variables for each transaction.
- The transaction_id is unique for each transaction processed. It is a 32-character string.
- The error_code returns 000 with a successful authorization. Additional error codes are provided in the Payment Gateway API document in the Materials section.
- The Auth_response is a textual representation of why the transaction approved/declined. If there is an error processing the transaction, a reason corresponding with the error_code will display here.
- The Avs_result displays 0 if no address or zip information is submitted. The auth_code will always be a 6 digit response from an issuing bank.
Authorizations from the Payment Simulator will always begin with a “T”.
Example Preauth request
A Pre-Authorization performs an authorization, but does not capture a transaction. This is useful in situations where validation of funds is desired immediately, however finalizing the transaction cannot happen at the time of authorization. This is typical in ecommerce environments which authorize at the time of checkout, but do not ‘settle’ the transaction until a product is shipped.
- POST /mes–api/tridentApi HTTP/1.1
Content–Type: application/x–www–form–urlencoded
Cache–Control: no–cache
Pragma: no–cache
User–Agent: Java/1.7.0_21
Host: cert.merchante–solutions.com
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Content-Length: xxx
profile_id=94100099999900000001&profile_key=A7B8C9A7A7B8C9A7A7B8C9A7A7B8C9A7&transaction_type=P&card_number=4262369999996102&card_exp_date=0409&transaction_amount=15&cardholder_street_address=920&cardholder_zip=99212&invoice_number=12345&tax_amount=0.01
Example Preauth response
- transaction_id=XXXX&error_code=000&auth_response_text=Approval TXXXXX&avs_result=0&auth_code=TXXXXX
Example Settle request
A Settle request captures funds for a Pre-Authorization. Settle requests accept a transaction_id from a previous Pre-Authorization.
- POST /mes–api/tridentApi HTTP/1.1
Content–Type: application/x–www–form–urlencoded
Cache–Control: no–cache
Pragma: no–cache
User–Agent: Java/1.7.0_21
Host: cert.merchante–solutions.com
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Content-Length: xxx
profile_id=94100099999900000001&profile_key=A7B8C9A7A7B8C9A7A7B8C9A7A7B8C9A7&transaction_type=S&transaction_id=8358aa9b20433aaabe35fd26996598fd
Example Settle response
- transaction_id=XXXX&error_code=000&auth_response_text=Settle Request Accepted
Example Refund request
A Refund will Void a transaction (when performed same-day as the authorization), or issue a credit (when performed the day after and beyond). Similar to a Settle request, a Refund accepts a transaction_id from any previous Sale or Settle — No card number is necessary.
- POST /mes–api/tridentApi HTTP/1.1
Content–Type: application/x–www–form–urlencoded
Cache–Control: no–cache
Pragma: no–cache
User–Agent: Java/1.7.0_21
Host: cert.merchante–solutions.com
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Content-Length: xxx
profile_id=94100099999900000001&profile_key=A7B8C9A7A7B8C9A7A7B8C9A7A7B8C9A7&transaction_type=U&transaction_id=8358aa9b20433aaabe35fd26996598fd
Example Refund response
- transaction_id=XXXX&error_code=000&auth_response_text=Refund Request Accepted – Void
For additional transaction types, fields, and features see the Payment Gateway API specification document.
