August 5, 2008 at 12:29authorize.net - connection and work
I happened to make an online store in which payment had to be carried out by credit cards. And it doesn’t matter if PayPal arranged the customer. More precisely, I didn’t know about it yet. The customer had a merchant account on authorize.net. During the search for a normal payment system, the authorization was rejected by me because of the wretchedness of the site. The site leaves a feeling that the project has long been abandoned, and no one is engaged in it. Anyway. The customer is always right. So.
What does a developer do first when faced with a standard task, but hitherto not implemented? Right! Goes to the Internet and is looking for ready-made solutions. It is possible that I'm a bad Google user. But, nevertheless, all ready-made implementations were nothing more than copies of the sample code taken on the site of the office. Neither you comments in the code, nor you accompanying note.
Next step: smoking Read the manual on the developer's site. The only thing that helped to do the manual was to understand what was 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 the site avtorayz.net
It should be noted that this data comes in two copies: Card Not Present and Card Present. The first one is when the seller does not receive a card in his hands 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). It allows you to keep a form filled out by the buyer and send data via SSL to the server of the service provider (in our case, Authorize.net)
2) Server Integration Method (SIM). In fact, the same thing will only provide you with an html form.
How to choose an API?
step 1: select the type of work. We have this Card Not Present.
step 2: is there any 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: whether to remember the user's session in the payment process. Yes - only AIM, no - you can SIM
In my case, only the AIM option was like. Therefore, we’ll talk about him. By the way, SIM is practically no different.
1) Array of parameters for the transaction.
What 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 the following form:
API Login: 6zz6m5N4Et
Transaction Key: 9V9wUv6Yd92t27t5
this is a test account, so you don’t need to immediately rub the pens
This array is taken from 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 - type of transaction.
x_amount - the amount of the transfer with two characters after the period. For example: 8.95 or 10.00. Length 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 - expiration date of the card. 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. The authorization code of the original transaction is not conducted on the gateway. Only needed if x_type = CAPTURE_ONLY
The rest of the parameters are, in principle, understandable. You can read about them in the manual if you wish.
I will describe only those in the example.
x_version - optional but highly recommended. Buyer Transaction Version. Format: 3.1 Version indicates a list of fields that the seller will receive in the server response.
x_delim_char - optional. The character by which the data in the response line will be divided.
x_delim_data - Required for AIM transactions. Indicated for a delimited response.
x_url - not described in the manual. But as I understand it, this is the URL to which the buyer will be redirected after the transaction.
x_method - optional. Payment method: CC (credit card) or ECHECK (electronic check). Format: CC, ECHECK.
x_relay_response - not described in the manual. Oo
x_description - 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. Optionally.
SpecialCode - not described in the manual.
2) Preparation of data for sending.
3) Sending data
4) In the sample code, all parameters coming in the server response are output. I have abbreviated this code to output the desired data.
That's all. This is the minimum necessary to carry out a successful transaction. I hope this article is useful to someone
What does a developer do first when faced with a standard task, but hitherto not implemented? Right! Goes to the Internet and is looking for ready-made solutions. It is possible that I'm a bad Google user. But, nevertheless, all ready-made implementations were nothing more than copies of the sample code taken on the site of the office. Neither you comments in the code, nor you accompanying note.
Next step: smoking Read the manual on the developer's site. The only thing that helped to do the manual was to understand what was 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 the site avtorayz.net
It should be noted that this data comes in two copies: Card Not Present and Card Present. The first one is when the seller does not receive a card in his hands 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). It allows you to keep a form filled out by the buyer and send data via SSL to the server of the service provider (in our case, Authorize.net)
2) Server Integration Method (SIM). In fact, the same thing will only provide you with an html form.
How to choose an API?
step 1: select the type of work. We have this Card Not Present.
step 2: is there any 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: whether to remember the user's session in the payment process. Yes - only AIM, no - you can SIM
In my case, only the AIM option was like. Therefore, we’ll talk about him. By the way, SIM is practically no different.
1) Array of parameters for the transaction.
What 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 the following form:
API Login: 6zz6m5N4Et
Transaction Key: 9V9wUv6Yd92t27t5
this is a test account, so you don’t need to immediately rub the pens
$ 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_d ″,
“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 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 - type of transaction.
Transaction types:
AUTH_CAPTURE - authorization and payment. All in one bottle. Checking the card and if everything is fine, we will immediately pay.
AUTH_ONLY - authorization only. Checking the card for validity. From the response you need to save Transaction ID
PRIOR_AUTH_CAPTURE - completes the transaction, which successfully passed authorization. This is what Transaction ID is for. Requirements: the original transaction was conducted no later than 30 days; Valid tansaction Id received the original transaction was not completed, did not expire, there was no error: the amount is less than or equal to the sum of the original transaction. The original transaction was carried out by the AUTH_ONLY method, as a result of which the Transaction ID was received.
CAPTURE_ONLY - ends a transaction that has not been sent to the gateway or requires voice confirmation. Essentially - manual confirmation in the merchant interface. That is, the seller must manually confirm this transaction on the autorize website. The required parameter is added:
x_auth_code = Authorization Code
CREDIT - used to return an already completed transaction. Additional parameters:
x_trans_id = Transaction ID
x_card_num = full card number or last 4 digits
Requirements: the transaction was successfully completed and the Transaction ID was received; the amount to return 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; Returns are made no later than 120 days.
VOID - to cancel the sent transaction to avoid processing it. Additional parameter: x_trans_id = Transaction ID
x_amount - the amount of the transfer with two characters after the period. For example: 8.95 or 10.00. Length 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 - expiration date of the card. 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. The authorization code of the original transaction is not conducted on the gateway. Only needed if x_type = CAPTURE_ONLY
The rest of the parameters are, in principle, understandable. You can read about them in the manual if you wish.
I will describe only those in the example.
x_version - optional but highly recommended. Buyer Transaction Version. Format: 3.1 Version indicates a list of fields that the seller will receive in the server response.
x_delim_char - optional. The character by which the data in the response line will be divided.
x_delim_data - Required for AIM transactions. Indicated for a delimited response.
x_url - not described in the manual. But as I understand it, this is the URL to which the buyer will be redirected after the transaction.
x_method - optional. Payment method: CC (credit card) or ECHECK (electronic check). Format: CC, ECHECK.
x_relay_response - not described in the manual. Oo
x_description - 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. Optionally.
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”);
// upper line for test accounts, lower line 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 answer
curl_setopt ($ ch, CURLOPT_RETURNTRANSFER, 1); // returns the answer if 1
curl_setopt ($ ch, CURLOPT_POSTFIELDS, rtrim ($ fields, “&”)); // use HTTP POST to to send data
// curl_setopt ($ ch, CURLOPT_SSL_VERIFYPEER, FALSE); // uncomment if you don't get any response from the server at all.
$ resp = curl_exec ($ ch); // execute post and get results
curl_close ($ ch);
4) In the sample code, all parameters coming in the server response are output. I have abbreviated this code to output the desired data.
for ($ j = 1; $ j <= $ h; $ j ++) {
$ p = strpos ($ text, “|”);
$ p ++;
$ pstr = substr ($ text, 0, $ p);
// prepares the text and returns the name-> value pairs
$ pstr_trimmed = substr ($ pstr, 0, -1); // removes “|" 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 determined, and work with the remaining line.
$ text = substr ($ text, $ p);
}
That's all. This is the minimum necessary to carry out a successful transaction. I hope this article is useful to someone
