BluSynergy supports the following Payment Gateways / Payment Processors with the high-level features supported.
| Gateway | Tokenization | CVV | AVS | ACH or eChecks | Account Updater | Notes | | Authorize.net | | x | x | x | | Fields should contain only alpha-numeric values
| | Authorize.net CIM (Customer Information Manager) | x | x | x | x | | Tokenization | | Chase Paymentech | | x | x
| x
| | Orbital Gateway requires client certificates
| | First Data Global Gateway | | x
| x
| | | FDGG requires client certificates
| | First Data Payeezy | | x | x | | | | Vantiv / WorldPay
| x | x | x | x | x | Advanced 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 Desktop (note this is being deprecated by Intuit)
| | Intuit Payments | x | x | x | x | | Default processor for QuickBooks Online | | Blue Pay | x | x | x | x | x/C | Quick signup, processor oriented towards B2B clients | | Chase Paymentech Orbital Gateway | | x | x | x | | | | Green by Phone | | | | x | | e-check processing only, high risk merchants accepted | | Willow Systems | | x | x | x | | | | Stripe | x | x | x | x | | Easy signup process | | Citruspay | | | | | | | | CCAvenue | | | | | | | | PayU | x | x | x | | | Overseas merchants | | First ACH | | | | x | | ACH only, high risk merchants accepted | | Intercept EFT | | | | x | | ACH/EFT only | | Payeezy (First Data) | x | x | x | x | | | | CC Avenue | x | x | x | | | Overseas merchants | | CardPoint | x | x | x | x | | | | First Data/Fiserv | x | x | x | x | x | Multiple gateways/processors from M&A, contact support | | Worldpay | x | x | x | x | x | Multiple gateways/processors from M&A, contact support | | FIS / Fidelity National Information Services | x | x | x | x | x | Multiple gateways/processors from M&A, contact support | | Litle | x | x | x | x | x | |
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 | Name | Required | Notes | | 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 ConfigurationWhen 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
| Number | Card type |
|---|
4242424242424242 | Visa | 4012888888881881 | Visa | 4000056655665556 | Visa (debit) | 5555555555554444 | MasterCard | 5200828282828210 | MasterCard (debit) | 5105105105105100 | MasterCard (prepaid) | 378282246310005 | American Express | 371449635398431 | American Express | 6011111111111117 | Discover | 6011000990139424 | Discover | 30569309025904 | Diners Club | 38520000023237 | Diners Club | 3530111333300000 | JCB | 3566002020360505 | JCB
|
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
- 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.
- If applicable, test using ACH. A valid bank routing number (ABA number) is required, the account number may be synthesized
- Find a successful payment and attempt a refund. Do this for both Credit Cards and ACH (if applicable).
- 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.
- 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.
- In the BluBilling system, save the card (or ACH) to the Customers profile and then attempt to make a payment using this saved card.
- If using tokenization, then verify that the above step created an entry in your merchant account for the new card.
- At the end of the day, compare reports in BluSynergy (Payment detail report) against the reports available on your processors' system.
- 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:
| No | Amount | Purchase Description contains keyword | Result | | 1. | (Any) | SLEEP | Simulates 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 | FAIL | Returns 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 | DECLINE | Returns 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 |
|
|
