Home‎ > ‎

Payment Gateways and Processors

BluSynergy supports the following Payment Gateways / Payment Processors with the high-level features supported. 

GatewayTokenizationCVV AVS ACH or eChecks  Account UpdaterNotes 
 Authorize.net  x x x  Fields should contain only alpha-numeric values
 Authorize.net CIM x x x  x   
 Chase Paymentech  x x
 x
  Orbital Gateway requires client certificates
 First Data Global Gateway  x
 x
   FDGG requires client certificates
 Vantiv (Litle)
 x x x x xAdvanced support for recurring billing features
 Lucy  x
 x
   
 Merchant e Solutions (MeS)        x/C x
 x
 x
 x/C
 
 Paypal PayFlow Pro  x x
   
 Paypal Website Payments Pro  x x   
 Quickbooks / Intuit Merchant Service  x x
   Intuit Merchant Service (IMS) is the default payment processor for accepting payments within Quickbooks
 Blue Pay x x x  x x/C Quick signup, processor oriented towards B2B clients


The payment processor is configured using the [System >> Payment Processor Configuration] menu and the essential configuration fields are noted below. Note that depending on the selected processor, the field names may adapt (change) to reflect the nomenclature used by that processor.

The basic configuration:

Fig 1. Basic payment processor settings


Using the "Payment Processor" list box, select the processor that you have signed up with.

The Login and Password fields is assigned by your processor (the field names may change to reflect the nomenclature used by that processor - in the example above it is called "API Login Id" and "Transaction Key" by authorize.net)

Clicking on the "Show Advanced Options" shows more fields:


Fig 2. Advanced options for the payment processor configuration.

The generic setting are outlined below. Y = Required, N = No, P = Processor dependent
 NameRequiredNotes 
 Account Id P See details for your specific processor
 Primary URL Y The URL provided by your payment processor. Note that most processors will have a production (or live) URL as well as a staging (or test) URL, so it is important to set the URL correctly depending on whether you are testing or live. Clicking on the "use default production link" will set the URL usually used by the selected payment gateway.
 Enable Batch Settlement N In this mode, payments will be  first authorized in real time and then settled ("captured") in batch mode during the night. Contact support if you require this feature.
 Tokenization N  If tokenization is enabled, then the sensitive credit card and ACH (bank) information is stored on the payment processor's systems instead of storing them in BluSynergy. Ensure that this feature is supported by your selected payment processor and that you have signed up for this service.
  Batch Payment Processing N In this mode, the automatic payments are processed in batches, instead of discrete transactions. Contact support if you require this feature.
 Use for Disbursement N  If payments will be disbursed via this processor (e.g., commissions or royalties), then this option must be selected.
 Enable AVS N If you configure Address Verification Service as a required option within your processor settings (by logging into your processor's website), then enable this option so that BluBilling will display the fields for the billing address along with the credit card fields.
 Enable ACH N  If your processor supports electronic check payments and you have signed up for this option, then select this option.
 Custom Fields 1 to 5 N  Processor dependent settings.



Click on the links below to review additional configuration settings for these payment processors.

Testing Your Payment Processor Configuration

When configuring a payment processor for the 1st time, we recommend the following test use cases. For the first pass, we recommend you test against the processor's staging/test environment and for the second round, we recommend testing against your processors' live/production environment using small amounts (eg. $1.00). This is a critical step since you will often find that transactions working fine in the test environment (such as tokenization, account updater, ACH etc.) are being declined in the production environment since separate enrollment is required.

The following test credit card numbers usually will work on your processor's staging environment. The expiration date must be set to a future date:

American Express Test Card 370000000000002
Visa Test Card 4111111111111111
Second Visa Test Card 4012888818888
MasterCard 5454545454545454

Some processors/gateways use specific test cards for each card types and you may wish to test against all these card types

NumberCard type
4242424242424242Visa
4012888888881881Visa
4000056655665556Visa (debit)
5555555555554444MasterCard
5200828282828210MasterCard (debit)
5105105105105100MasterCard (prepaid)
378282246310005American Express
371449635398431American Express
6011111111111117Discover
6011000990139424Discover
30569309025904Diners Club
38520000023237Diners Club
3530111333300000JCB
3566002020360505JCB

For testing ACH transactions, any valid Bank Routing Numbers will work, the Account Number may be made up. These are some test routing numbers used by some processors/gateways:
021000021
011401533
091000019

A full list of valid routing numbers may be found here: http://www.fedwiredirectory.frb.org/reserve.cfm

  1. Test a payment using each of the major credit card types that you support (Mastercard, Visa, Discover, Amex). Note that test card numbers that will NOT work in the production environment.
  2. If applicable, test using ACH. A valid bank routing number (ABA number) is required, the account number may be synthesized
  3. Find a successful payment and attempt a refund. Do this for both Credit Cards and ACH (if applicable).
  4. If AVS is enabled on your merchant account, then test and verify expected results when you provide the billing address and when you do not provide the billing address.
  5. If CVV (Card Validation Value) is enabled on your merchant account, then test and verify expected results when you provide the CVV and when you do not provide the CVV.
  6. In the BluBilling system, save the card (or ACH) to the Customers profile and then attempt to make a payment using this saved card.
  7. If using tokenization, then verify that the above step created an entry in your merchant account for the new card.
  8. At the end of the day, compare reports in BluSynergy (Payment detail report) against the reports available on your processors' system.
  9. Verify funding by monitoring your bank account and understand the funding cycle (usually 1 to 2 business days) and the settlement mode used by your acquirer (gross settlement vs. net settlement).
The "Test Processor" is a dummy payment processor that may be used to simulate various results by sending various amounts and/or keywords in the payment description as noted below:


 NoAmount Purchase Description contains keyword Result
 1. (Any) SLEEPSimulates 60 second delay - use to test your calling systems in the event your payment processor takes a long time to return a result. Typically, a user would have retried the transaction or navigated away in the event of a long delay
 2.  EXCEPTION Throws an exception (error)
 3. ends with 0.33 FAILReturns a system status of error. 
 statusMessage: "Simulating socket error"
 errorMessage: "Communication link failure (simulated)"
This error may also be simulated by using an expiry date of "12/31/2098"
 4. ends with 0.66 DECLINEReturns a system status of declined. 
 statusMessage: "Simulating declined payment"

This error may also be simulated by using an expiry date of "12/31/2099
 5. all others Returns a status of approved