Advanced Level Linking

Please contact Swreg prior to starting development to confirm you are eligible to use the feature. In addition, study the Intermediate Level as you will need to understand the concepts before proceeding here. This especially applies to multiple products per order.

The Advanced Level principle is that you collect all the order information on your own secure server, you then POST the information to our program called https://usd.swreg.org/cgi-bin/c.cgi that returns a string containing a result code, a currency, type of purchase (i.e., realtime, by fax, by phone, etc), an order number, and a value in your own default currency (See below table for further details). On receipt of that string you will produce a web page for your customer incorporating template web pages stored on our website (you must link to them rather than store them locally as they can change from time to time). Meanwhile we will operate exactly as Basic and Advanced levels in sending out emails, storing transactions, etc.

Result Parameters

Parameters that may be returned by check payment processing

Parameters that may be returned by electronic/wire payment processing

Active until October 1st, 2008 (Please discontinue using before this date)

Please go to a live working site now at http://www.evidence-eliminator.com - this is from our second busiest vendor, Andy Churchill, to whom we are indebted for assistance in developing this system, and is working in anger right now. Feel free to do a test using the "By Phone" or "By Fax" orders but make it clear in your address it is a test purchase so Evidence Eliminator can ignore them in the Pending Orders report. (Of course you could always buy a copy)!! Click here to download Andy's PERL source code for adaption by yourself.

You may wish to lift the source code for the list of countries we sell to from https://usd.swreg.org/cgi-bin/s.cgi?s=43387&p=433871&v=0&d=0&q=1&t=

Now look at the web page at http://swreg.org/tester.htm - you will see a test page listing all the variables we need - you should study the code on this page to see how it works. All variables are required to be POSTed but a list of variables that must have data is shown with an asterisk. All variables not required to have a value must still be sent as a null value (this can simply be an = sign like "x=")

What happens when you submit our sample page is that it sends a string to our program at https://usd.swreg.org/cgi-bin/c.cgi

If the order is successful you will get back a zero (0). If the order fails, a non-zero value with be returned. Possible return values are available here.

RULES:

When not a realtime credit card order you need to supply the following web pages in a frame with your pricing confirmation at the top and the following information at the bottom. The information at the top must always quote the Order Number prominently - this is one of the returned values from our server.

• "By Fax" - place http://swreg.org/fax_ordering.htm in the lower frame. Remind people there is a $3 surcharge for ordering this way and that they must use the same email address as already on Paypal or the order will fail.
• "By Phone" - place http://swreg.org/phone_ordering.htm in the lower frame. Remind people there is a $3 surcharge for ordering this way.
• "By Check" or "By Wire" or "By Electronic Funds Transfer" - Remind people there is a $3 surcharge for ordering by check and an $20 surcharge for wire transfer. We will return the information to make the payment in the parameters listed at the top of this page for check or wire payment processing.
• TEST PURCHASES - If the purpose of testing is to test your communications with our server then you can test the results with credit card number 5555555555555555 (5 x 16). You will get a simple page returned with the word "Test Mode" and a list of all variables you have sent. This proves communication with our server. You will not get any transactions logged even in the Pending Orders database, nor any test emails. You can also try using card 36000000000008 which should give you a failure although it should appear as "Test Completed" in the Pending and Failed orders table - if it does show "Test Complete" or "Declined" it proves communication through to our bank. Another way to do an online test is to use the "By Phone" or "By Fax" options. If you wish to test the email layouts then you need to use the Test Order button on each product data entry page online.
• Remember you can select currency and you can select method of payment.

On a multiple product order you only enter the general variables (name, address, etc) once. All transaction variables can be entered just like the Intermediate method described above.

Currencies: The best practice is to display and charge your customer in their native currency. You can convert USD to other world currencies by calling http://usd.swreg.org/cgi-bin/rate-calculator.cgi?currency=GBP. Where GBP is the international 3 letter currency code. This will return the conversion rate we are using at that moment so you will need to multiply USD by that rate to get an approximation of what will appear on the customer's credit card. Then you will pass the currency to charge the customer with the c= parameter. We will return the amount and currency of the charge. There are currencies that we do not have exchange rates, the rate calculator will return 0.000000 in these cases.

For a list of supported currencies please visit:

https://usd.swreg.org/cgi-bin/s.cgi?s=43387&p=433871&v=0&d=0&q=1&t=

MORE RULES:

Please keep an eye on these rules as they may change form time to time until we have worked them all out from experience.

• You must collect IP number (see above)
• You must transmit to us required variables, but you do not need to passed optional variables - see the page at http://swreg.org/tester.htm for a list of required values.
• By "quotation" we mean the display to the customer showing process before the customer commits to final purchase
• You should do the same for VAT if you need it collecting although you should be able to calculate and display this ideally
• Always make clear on the final page after a realtime sale how the charge will appear on their credit card (Use the soft_descriptor parameter passed back from Swreg
• If you receive your own payments from us via BACS or UK cheque the currency value returned by us will be in GBP otherwise USD - ONLY FOR REALTIME TRANSACTIONS - for non-realtime transactions (i.e., by fax) the result will be in USD.
• You can send out a string to our server from a cgi program or directly from a web page. You will always need the response to be sent to a cgi program at your end in order to select the correct response for your customer. If you are using the same cgi program to both send the string and receive the response you do not use the Return Address variable and can leave it set as ra=<null> but if you are transmitting straight from a web page form or need the result to be sent to a different cgi program you will need to use the value ra=<URL to respond to>.
• Please make data in the State field compulsory if USA entered as the country.
• Payment options are (1) Realtime credit card (2) By Fax - credit card (3) By Phone - credit card (7) Purchase order by ACH if in USD/CAD, by EFT if in EUR/CAD or by BACS if in GBP. (8) Purchase order by Wire and (9) Purchase order by cheque/check, (10) Purchase order by Local Wire.
• IMPORTANT: In order to send us secure strings you must have LWP (libwww-perl) and Crypt-SSLeay installed in your Perl setup on your server. Ask your ISP to install those modules. These are common modules installed on many servers, it shouldn't cost you anything. It takes a couple of minutes at the ISP.
• How to handle error 21 "Call Authorisation Centre". Please display text similar to that at http://swreg.org/call_auth_centre.htm
• Error 22 comms failure. I suggest thanking them for the order, "there has been a communications problem with their bank but we will try again each hour until completed at which point you will receive an emailed receipt. Please do not attempt to re-order. Any queries please click here but please allow a couple of hours before writing in."
• On your Submit button in giant letters flashing with neon nymphettes please show something like "WARNING: ONLY PRESS ONCE OR YOU MAY BE CHARGED MORE THAN ONCE. IT CAN TAKE UP TO 2 MINUTES TO PROCESS YOUR CARD" In fact it only takes a few seconds but people are impatient and if they click twice the first pipe is broken so even we cannot tell if the card has been charged. This is a classic e-commerce problem. One solution is to issue a serial number with each page that has the final Pay Now button on it. When the page is clicked the serial number is passed back to your cgi that ignores any but the first click.
• Create a system to identify double clicks and ignore them - see the bit about serializing served web pages above paragraph.
• Diner's Club has a 4% surcharge automatically added to the customer's bill due to their higher commission rates.
• SUPPORT: We cannot give programming advice - the samples are to show you how it can be done but that is just one way - you are welcome to adapt the sample code given above - but we are happy to give general implementation advice by clicking here

VAT Issues

You must assume that the local VAT rate will be added to any EU shipping address order - that includes any $3 manual processing fees. You can call a cgi called vnv.cgi to determine the VAT rate. There are some instructions at :-

http://usd.swreg.org/vnv.htm

Please list on the receipt as:

• Price
• VAT @ member state rate
• Total

As part of the address you will need to collect the customer's VAT number. It must be in the format of two letters and a series of numbers (max 15 characters) i.e. GB445812740 in that format. If the customer enters a VAT number, you must pass it to c.cgi in the vn=<number> parameter. You can use the vnv.cgi module to validate the VAT number is in an acceptable format.

If this field is completed, and the customer is not in the EU please make the following information available on the receipt page - and possibly prior to order completion if you feel it may help.

Sold by:

SWREG Inc.
9625 West 76^th Street
Eden Prairie, MN 55344
USA

Our VAT Reg. # EU826011714
Your VAT #: FR123456789

"If you are a company within the European Union and did not provide or do not have a VAT number, you can obtain the VAT refund from your taxing authority provided you are VAT exempt. We are unable to refund the VAT tax from a completed order."

A list of country names we accept is available by grabbing the from the following URL :-

https://usd.swreg.org/cgi-bin/s.cgi?s=43387&p=433871&v=0&d=0&q=1&t=

Additional Information

• Dynamic soft descriptors. We now support dynamic soft descriptors based on the the items the customer ordered. We are passing this information back to you in return query string from the advanced level API. You set the option in the "Author Details." to determine what we should base the soft descriptor on.
• We have added a variable for the 3-number CVV2/CSC field, the number on the back of the credit card. It is 'csc=nnn' (lower case)

• We have updated the variable vt=n to your cgi call to prevent us duplicating orders from yourself. You give each order a unique token up to 30 characters. This will ensure that we will not allow an order to be repeated if we have already logged an order with the same token.

  You can also interrogate https://usd.swreg.org/cgi-bin/token2order.pl with three arguments sent as a post (You cannot send as a GET): shop_id (your store number), token_id, and password. The password is specified by you through your author details via the "API Password" field.

  Results are sent as plain text. Each result name/value pair is on its own line: Name/value pairs: StatusCode StatusMessage TokenId OrderId ErrorCode

  Here are two call examples: perl and html.

• You can generate printable receipts by following the instructions listed here

Return to Summary >>