authorize.net - connect and work

I had a chance to make an online store in which you had to pay with credit cards. And it doesn’t matter if PayPal arranged the customer. I didn’t know about that yet. The customer had a merchant account on authorize.net. During the search for a normal payment system, the autorise was dropped by me due to the wretchedness of the site. The site leaves a feeling that the project has long been abandoned, and no one does it. Anyway. The customer is always right. So.

What does the developer do first of all when faced with the standard task, but which he has not yet implemented? Right! Goes to the Internet and looking for ready-made solutions. It’s possible that I’m a bad Google user. But, nevertheless - all ready implementations were nothing more than copies of the sample code taken on the site of the office. Neither you have comments in the code, nor you accompanying note.

The next step: smoking the manual on the developer's site. The only thing that helped make the manual is to understand what is really superfluous in the sample code. Next, I offer my tips on working with this service. This is partly a translation of the manual, and personal experience.
')

To work, you need either a merchant account or a test. You can get a test on site autoriz.net

It should be noted that these data come in two copies: Card Not Present and Card Present. The first is the option when the seller does not receive a card to verify the entered data by the user. The second is the opposite. We are interested in the first.

There are several options for integrating the service to your site.

1) Advanced Integration Method (AIM). Allows you to keep the form filled by the buyer and send the data via SSL to the server of the service provider (in our case, Authorize.net)

2) Server Integration Method (SIM). Practically the same thing will only provide you with another html form.

How to choose an API?

Step 1: Select the type of work. We have this Card Not Present.

Step 2: Is there SSL on your host? if there is - you can use AIM, if not - you need to use SIM.

Step 3: Do you need the form to point to your domain? if yes - you need to use AIM, if not - you can SIM

Step 4: Do I need to memorize a user session during the payment process? Yes - only AIM, no - you can SIM

In my case, only the AIM variant was like. Therefore, about him and talk. By the way - SIM is practically no different.
1) Array of parameters for conducting a transaction.

What do we need? Merchant or test account.

$ auth_net_login_id and $ autn_net_tran_key - login and transaction key.

They come to the mail in this form:
API Login: 6zz6m5N4Et
Transaction Key: 9V9wUv6Yd92t27t5
This is a test account, so you do not need to immediately rub your hands

$ authnet_values ​​= array
(
“X_login” => $ auth_net_login_id,
“X_version” => “3.1 ″,
“X_delim_char” => “|”,
“X_delim_data” => “TRUE”,
“X_url” => “FALSE”,
“X_type” => “AUTH_CAPTURE”,
“X_method” => “CC”,
“X_tran_key” => $ auth_net_tran_key,
“X_relay_response” => “FALSE”,
“X_card_num” => “4242424242424242 ″,
“X_exp_date” => “1209 ″,
“X_description” => “Recycled Toner Cartridges”,
“X_amount” => “12.23 ″,
“X_first_name” => “Charles D.”,
“X_last_name” => “Gaulle”,
“X_address” => “342 N. Main Street # 150 ″,
“X_city” => “Ft. Worth ”,
“X_state” => “TX”,
“X_zip” => “12345 ″,
“CustomerBirthMonth” => “Customer Birth Month: 12 ″,
“CustomerBirthDay” => “Customer Birth Day: 1 ″,
“CustomerBirthYear” => “Customer Birth Year: 1959 ″,
“SpecialCode” => “Promotion: Spring Sale”,
);

This array is taken from the sample code. Let's see what all this means and whether we really need it.

Required parameters:

x_login - API Login ID.

x_tran_key - Transaction Key

x_type is a transaction type.

Types of transactions:

AUTH_CAPTURE - authorization and payment. All in one bottle. Verification of the card and if everything is good - we will immediately pay for it.

AUTH_ONLY - only authorization. Checking the card for validity. From the answer you need to save Transaction ID

PRIOR_AUTH_CAPTURE - completes the transaction that successfully passed the authorization. This is what the Transaction ID is for. Requirements: the original transaction was completed no later than 30 days; received valid tansaction Id; The original transaction was not executed, did not expire, there was no error: the amount is less than or equal to the amount from the original transaction. The original transaction is performed by the AUTH_ONLY method, as a result of which a Transaction ID was received.

CAPTURE_ONLY — Terminates a transaction that was not sent to the gateway or requires voice confirmation. In fact - manual confirmation in the merchant interface. That is, the seller must manually confirm this transaction on the website of the author. Added required parameter:

x_auth_code = Authorization Code

CREDIT - used to return an already completed transaction. Extra options:

x_trans_id = Transaction ID
x_card_num = full card number or last 4 digits
Requirements: the transaction was successfully completed and a Transaction ID was received; the amount to be returned is less than or equal to the amount paid; if the return was made in parts - the amount is less than or equal to the paid; Refund is held no later than 120 days.

VOID - to cancel a sent transaction to avoid processing it. Additional parameter: x_trans_id = Transaction ID

x_amount - the amount of transfer with two characters after the point. For example: 8.95 or 10.00. Up to 15 characters.

x_card_num - from 13 to 16 digits - card number without spaces. If x_type = CREDIT - only the last 4 digits.

x_exp_date - card expiration date. Formats: MMYY, MM / YY, MM-YY, MMYYYY, MM / YYYY, MM-YYYY

x_trans_id - transaction ID. Only needed if x_type = CREDIT, PRIOR_AUTH_CAPTURE, or VOID

x_auth_code - 6 characters. Authorization code of the original transaction not performed on the gateway. Only needed if x_type = CAPTURE_ONLY

The remaining parameters are in principle understandable and so. About them, if desired, you can read in the manual.

I will describe only given in the example.

x_version is optional but highly recommended. The transaction version of the buyer. Format: 3.1 Version indicates the list of fields that the seller will receive in the server response.

x_delim_char - optional. The character that will be separated in the response line.

x_delim_data - Required for AIM transactions. Indicated to receive a delimited response.

x_url - not described in the manual. But as far as I understand, this is the URL to which the buyer’s redirect will be made after the transaction.

x_method is optional. Payment method: CC (credit card) or ECHECK (electronic check). Format: CC, ECHECK.

x_relay_response - not described in the manual. Ooh

x_description is optional. Description of the transaction. Up to 255 characters.

x_first_name, x_last_name, x_address, x_city, x_state, x_zip, CustomerBirthMonth, CustomerBirthDay, CustomerBirthYear - customer data. Optional.

SpecialCode - not described in the manual.
2) Preparation of data for sending.

fields = “”;
foreach ($ authnet_values ​​as $ key => $ value) $ fields. = “$ key =”. urlencode ($ value). “&”;

3) Sending data

$ ch = curl_init ("https://test.authorize.net/gateway/transact.dll");
// top line for test accounts, bottom for merchant
// $ ch = curl_init ("https://secure.authorize.net/gateway/transact.dll");
curl_setopt ($ ch, CURLOPT_HEADER, 0); // set to 0 to remove header info from the response
curl_setopt ($ ch, CURLOPT_RETURNTRANSFER, 1); // returns the answer if 1
curl_setopt ($ ch, CURLOPT_POSTFIELDS, rtrim ($ fields, “&”)); // use HTTP POST to send data
// curl_setopt ($ ch, CURLOPT_SSL_VERIFYPEER, FALSE); // uncomment if you don’t receive any response from the server at all.
$ resp = curl_exec ($ ch); // execute post and get results
curl_close ($ ch);

4) In the sample code, the output of all parameters arriving in the server response is made. I have shortened this code to display the necessary data.

for ($ j = 1; $ j <= $ h; $ j ++) {
$ p = strpos ($ text, “|”);
$ p ++;
$ pstr = substr ($ text, 0, $ p);

// prepares text and returns name-> value pairs
$ pstr_trimmed = substr ($ pstr, 0, -1); // deletes the “|” at the end of the line.

if ($ pstr_trimmed == ”") {
$ pstr_trimmed = ”NO VALUE RETURNED”;
}

if ($ j == 1) {
$ fval = "";
if ($ pstr_trimmed == ”1 ″) {
$ fval = ”Approved”;
} elseif ($ pstr_trimmed == ”2 ″) {
$ fval = "Declined";
} elseif ($ pstr_trimmed == ”3 ″) {
$ fval = ”Error”;
}
} elseif ($ j == 7) {
// transaction ID
$ trans_id = $ pstr_trimmed;
}
// remove the part that has already been defined, and work with the remaining line.
$ text = substr ($ text, $ p);
}

That's all. This is the minimum required for a successful transaction. I hope this article is useful to someone.