Understanding Payment Gateways

1.

Introduction

There are 3 main ways of accepting payments online. You can use a payment gateway (seamless or non-seamless) to process credit card payments immediately through a payment gateway, you can collect credit card details for offline processing or you can use offline payment methods such as COD, Cheque or Direct Debit and then mark your orders as paid once you check your bank account. Note: You can only use one payment gateway per website plus PayPal Standard. You can use as many offline processing method as you require. You can see all available options in Cusomizing Registration Form article.

2.

Seamless vs Non-seamless payment gateways

A seamless payment gateway is one that processes credit cards directly on your online shop website without redirecting the purchasing customer to any 3rd party website. The whole transaction is seamless and takes place in real-time. On the other hand a non-seamless payment gateway such as PayPal will redirect the purchasing customer to the PayPal website to process the payment and will redirect the customer back to the online shop after this has been completed.

3.

Must I use a payment gateway?

You can select not to use a payment gateway and still receive payments through your site. Payment Gateways are great because the sale goes through (almost) instantly, and both you and your customer receive appropriate feedback that the payment has been received. However, the system also allows you to process payments offline, which means that the customer's credit card details are sent to you so that you can process it yourself, in your own time.

4.

Payment gateways and recurring payments

The system allows you to accept recurring orders, This is when you create an order which reoccurs periodically, and automatically charges the customer's credit card. If you are going to be creating orders like this to collect recurring payments (for example, subscription payments), you must select a payment gateway that supports them. To see the list of gateways which support recurring billing you can see Gateways which support recurring biling article and click on the gateway name for specific information for that gateway.

5.

Complete list of currently supported payment gateways

The following is the list of supported gateways, the countries they may be used in, if they're seamless or not, if they support recurrance and anti-freud. No Payment Gateway's List on Production Country List Type Recurring payments Integrated Gateway AntiFraud Protection

1 2 3 4

Authorize.net Banco Popular Payment Gateway

US Puerto Rico

seamless nonseamless seamless seamless

Yes -

ALL ALL ALL

6 7 8 9 10

Beanstream Payment Canada Gateway CyberSource Gateway US,AU,CH,IN,MX,SG, UK,ZA and Euro Countries DIBS Payment DK,SE,NO,CH,TR,NZ,J Gateway P,IS,CA,AU,UK,US and Euro Countries India EBS Payment Gateway EWay Gateway Most Countries Google Checkout US, UK HeidelPay Payment Gateway InternetSecure Authorize Payment Gateway MIGS Payment Gateway Mollie Payment Gateway Moneris Gateway National Australia Bank (NAB) Gateway Most European Countries Most Countries

nonseamless nonseamless seamless nonseamless nonseamless seamless

Yes -

BEAGLE ALL

11 12 13 14

AU Only Netherlands only Canada Only AU, CA, US, UK, JP, HK, NZ, SG and Euro Countries US, CA, AU, NZ and Euro Countries US, CA, AU, NZ and Euro Countries AU Euro Area US,CA,UK and Most Countries South Africa only US, UK, AU, NZ, ZA,

seamless nonseamless seamless seamless

AVS, CVD CCV

15 NetBanx Payment Gateway (API integration) 16 NetBanx Payment Gateway (UPP integration) 17 NetRegistry Payment Gateway 18 Ogone Payment Gateway 19 Optimal Payment Gateway 20 PayGate Payment Gateway 21 Payment Express (PX

seamless

ALL

nonseamless seamless seamless seamless seamless non-

Yes -

CCV ALL ALL -

Pay Non-Seamless) Gateway 22 Payment Express (Seamless) Gateway 23 PayPal PayFlow Payment Gateway 24 PayPal Website Payments Pro Payment Gateway 25 Paypal Website Standard 26 Process Offline (process manually via existing facility) 27 RealEx Payment Gateway 28 SaferPay (Seamless) Gateway 29 SaferPay Gateway (Hosted solution) 30 Sage Pay (Protx) Payment Gateway

SG, MY and Pacific Islands US, UK, AU, NZ, ZA, SG, MY and Pacific Islands US, CA, AU, NZ, SG US,CA,UK only

seamless seamless AVS

seamless seamless

Yes

ALL ALL

US, AU and Euro Countries -

nonseamless -

Ireland, UK

31 SecurePay (ESEC) Gateway 32 Valitor Payment Gateway 33 WebPay Payment Gateway 34 WorldPay Gateway

nonseamless US,UK,CH,SE,DK,PL,C seamless Z Most Countries nonseamless AU,CA,CH,DK,UK,HK, seamless ID,JP,LU,NO,NZ,SE,SG ,TR,US and Euro Countries AU seamless Iceland seamless

Yes

ALL ALL

AU,US,CA,GB,HR,NO, seamless PL,JP,HU,CH,DK,SK,S E,CZ and Euro Countries International seamless

6.

Payment Gateway security

Although we provide up to date security measures to protect your site against fraudulent users, we recommend you to also take advantage of the anti-fraud systems provided by each payment gateway. Contact your payment gateway provider for further assistance.
7.

Setting up your payment gateway

After logging into your admin console, navigate to eCommerce > Payment gateways. You will need to select the country code you want to assign this gateway to inside Country to configure for: dropdown. This country will need to match the country of the domain names you have added to your site under Site Settings > Site Domains.

Each Payment Gateway has a different requirement, and as such you will be asked to input different items (such as user account name, merchant ID, transaction key, etc) depending on the gateway provider. Select the gateway you wish to use and you will see what details you need to provide for that gateway.

8.

Testing payment gateways

The best way to test a payment gateway operation is to Create a 1 cent product, and add it to your catalogue. Purchase the product using all available payment methods. Ensure the order is created. If using PayPal, ensure the payment status is set to success Check your invoice that you were emailed Ensure the site owner has received their order workflow notification. Using the payment gateway's test gateways is possible, however often requires special credentials and card details to be used...and we do not recommend it unless absolutely necessary. When testing your gateway you can use this site to reference test cards if needed. http://www.infomerchant.net/creditcardprocessing/credit_card_test_numbers.html

How to Test Payment Gateway Functionality? To test payment gateway functionality is same as test any other functionality. You should have some test strategy during testing it. Following are some points keep in mind during testing of payment gateway.
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.

Gather appropriate test data for the dummy credit card numbers for various master cards. Gather payment gateway information like whether used paypal, guestpay etc. Gather payment gateway documents with error codes useful it if any error came during testing to identify whether its our application fault or payment gateway related error. Does the gateway do what it is supposed to do? Does it handle order objects correctly? Does it perform additional calculations correctly? Understanding of the integration of the payment gateway with application Understand and test the parameters and sessions passed through payment gateway and application Understand and test the amount related information passed through query string or session or variables in any form. Check the format of the amount with currency format Check the language of the application and payment gateway language Try to change payment gateway language during the payment process Test after successful payment all the necessary data retrieved to our application or not Check what happens if payment gateway goes down during the payment process Check what happens if payment process went successful but do not return to our application

14. Check what happens if session goes time out during the payment process 15. Check what happens in backend during the payment process is the session data stored in

temporary table or any id is generated or not?

16. Check what happens if payment process is fail 17. Check if any modification transaction is going on through payment gateway, then how

18. 19. 20. 21. 22. 23.

much amount is taken out as modified amount whether required to pay more or not. For example- if modified amount is greater than paid amount then and then only application redirect to payment gateway otherwise it should not. Verify DB entries for the transaction whether they store credit card details and all or not Verify DB entries for the amount related fields in database for the fresh transaction, modified transaction and canceled transaction. Verify error page during payment gateway process Verify security passes for the transaction Sometimes payment gateway sent confirmation through popup dialogs so test popup blocker related settings also. What happens is popup blocker is on and all this. Check buffer pages between application and payment gateway (firefox firebug add-on will be helpful to test)

Hope guys, it will be helpful to you in your testing. If any new points are there then update it in comments, so I also get update in my knowledge.

You need to approach your testing of the payment gateway much like you would any other feature -- by documenting (and getting buy-in on) a concise test strategy. A search of Google for "Test plan" or "Test spec" will produce several templates that can drive your strategy, but here are some key points to consider: Functionality: This is the act of testing base functionality. Does the gateway do what it is supposed to do? Does it handle order objects correctly? Does it perform additional calculations correctly? (For instance, if the gateway will be run in a country with a VAT added at payment time, is that calculated correctly?) Integration: Next, you need to test integration with your credit-card service. This could arguably be clubbed with the functionality testing, but to me it's sufficiently important that it deserves its own category. Don't just focus on "positive cases" here. It's important to the company that it bill (and be reimbursed) for the right amount, but it's also critical that every possible billing error be handled appropriately by the gateway. You need to do this testing with a clear definition of the card payment system in-hand. Security: Next, you have to perform a deep security pass. Of course you want to look for things like buffer overruns. But today's hacker is generally more sophisticated than that, and you need to test accordingly. Searching for "security testing" or "security hacks" will yield much. Some blogs to consider

9.

Test cases for payment gateway

Test cases for payment gateway: My example is PayPal manager based:1) Test with valid card number with valid expiry but invalid CVV. 2) Test with valid card number with invalid expiry but valid CVV. 3) Test with valid card number with invalid expiry and CVV. 4) Test with valid details of expired/blocked card. 5) Test with valid card number, CVV and expiry date. 6) Test for reference transaction. 7) Test for billing/shipping details in payment manager. 8) Test for back payment to customer. 9) Test for "0" transaction. 10) Test for negative transaction.

Test cases for payment gateway 1. UI Validations (Page/Field Level, Tab Order, dropdown values, Page Back/Forward Navigation, Look and Feel for consistency with rest of the pages in application, Text Font, Size, Justification, Help Text, Cursor Text, Mandatory fields, etc..) 2. Transaction Flow - Happy scenario - Enter all valid data and get a confirmation 3. Negative scenarios - You can add n number of negative scenarios for a transaction to fail 4. Data security - Most important thing to test with credit cards. (cache, history, masked data, etc..) 5. Performance - Time taken for a transaction.

The only way to know for sure that a merchant account and payment gateway are set up/integrated properly is to run a live transaction. Having said that, this is rarely necessary. Incorrect integration of a payment gateway and merchant account is rare and can be discovered by running a live transaction with a test credit card. If the sale is declined then the integration is correct and no funds are actually processed. If it isn't then you have found the problem and can have it corrected without actually having to charge someone's credit card. To test the integration, a test account with the payment gateway would certainly suffice. If your integration with the test payment gateway account works properly it is going to work on the live site, too. If it doesn't then the test environment is poorly done and should be a red flag that a new payment gateway provider may need to be selected (but this won't happen as all major payment gateways have reliable testing capabilities). Thanks for your insight John. In this particular case, I have already integrated my shopping cart into their test account. However, every test CC# (and accompanying CVV's) produces a negative response. On top of that, the negative responses are returned with no response codes. When asked

about that, customer service says I will not get a response because 'because no real AVS or CVV data is being queried.' How in the world am I supposed to see a positive response? For example, Auth.net sends back an auto-email with transaction and authorization codes. If you're getting a negative response then there's a problem with your integration. Every transaction using an Authnet test account will be successful unless you intentionally send information to make it return an error or decline. This includes AVS and CVV responses. Additionally, their APIs document how to receive a response from each transaction. It differs depending on the API. Depends on whats in the module. If its one of the payment gateways like paypal/ ccavenue etc, they all provide a sandbox model, where you can make small payments and not claim them... so it gets cancelled. Read up the integration guide of that payment gateway. every provider has one. It all Depends on the payment gateway 1. For Amazon / Paypal /Google Checkout we need the Sandbox server to test with dummy accounts. 2. For the Trust commerce/ Authorize Net they Support the dummy/test cards. we can configure the test server for testing and able to do big payments also.

The Test Gateway allows you to simulate an end to end transaction as if it were configured for a real payment gateway. This is for testing purposes only and should not be enabled on a production site. If you don't have a payment gateway, you can operate the system in reservation mode only where no payment is required. You can also operate many of our real payment gateways in sandbox or test mode. The Test Gateway will accept the following credit card numbers: American Express: 378282246310005 Diners Club: 30569309025904 Discover: 6011111111111117 JCB: 3530111333300000 MasterCard: 5555555555554444 Visa: 4111111111111111 The expiry date must be valid (in the future), and the CVC can be any 3 or 4 digit number. To test a failed payment attempt, you can use the CVC 000. You can use the Test Gateway from your customer facing booking page, or internally via "Add Payment" or when applying a refund.

2. Test Credit Card Numbers

Gateways often have test modes where you can use test card numbers. The common test card numbers are below and should generate successful test transactions but they can vary from gateway to gateway. You may use any expiration date in the future. 4007000000027 - Visa Test Card 4012888818888 - Visa Test Card II 5424000000000015 - MasterCard Test Card 370000000000002 - American Express Test Card 6011000000000012 - Discover Test Card 3088000000000017 - JCB Test Card (Use expiration date 0905) 38000000000006 - Diners Club/Carte Blanche Test (Use expiration date 0905)

While testing the payment gateway for some eCommerce site, is there any way to check if the cookies are saving the user's credit card details? If so, can we verify if they are in encrypted form? Beyond just looking at the content of the cookies? (You can also check the scope and expiry of cookies and whether the gateway works if the cookies are not accepted) However, if you don't find the CC details they could be encrypted or disguised but that won't tell you how well encrypted they are. Obtaining a statement from the gateway provider may be the only way forward if the CC details are not obvious in the cookie