What is the payment flow from beginning to end of an ecommerce transaction? This is the credit card processing payment flow for MOST but not all gateways.

1. If ecommerce, the customer places an order. The ecommerce solution defines what data will be passed to the gateway. It uses an API to pass specified data to the gateway.
2. The gateway receives the transaction information and securely passes it to the payment processor.  Each gateway defines what data it will pass to the processor and it may collect more information than it passes. Each processor defines what information it will accept from a gateway.  The API uses the approved data and data format. The gateway must be certified to connect to the processor via a rigorous approval process to ensure security. The gateway transaction file includes yes/no parameters that were predetermined at the account set up level. For example, the “zip code must match or decline the transaction”. The gateway may also kill the transaction before sending to the processor based on merchant risk parameters that were set up.
3. The processor submits to credit card interchange network.
4. The credit card interchange network routes the transaction to the customers credit card issuer.
5. The credit card issuer approves or declines.
6. The credit card interchange network relays the answer back to the processor.
7. The processor records the transaction details and deposits funds in your account per your merchant account terms. It relays the results to the gateway.
8. The gateway records the transaction results and passes it to the ecommerce solution, which then stores on the customer record.  Again, the ecommerce solution defines which data it will accept from the gateway.

At the very beginning I noted the above applies for most but not all gateways. The exception is if the gateway is also a switch. In that case, the switch can bypass steps and go straight to the credit card issuer. This is more rare and none of the most popular gateways can do this.

No. Our hosted payment processing platform is NOT in a cloud. On the surface there are similarities, but the reason not to use a cloud is to control the integrity of the entire system from security to reliability. Amazon’s cloud failure, now impacting businesses for the second day, is the perfect example of why we will not use cloud computing for payment processing related services.

In cloud computing, the user’s computer may contain almost no software or data (perhaps a minimal operating system and web browser only), serving as little more than a display terminal for processes occurring on a network of computers far away.

In our hosted payments solution, the user’s computer will only need a small bit of software if using a signature capture terminal. All users connect to the platform via a web browser (except mobile). Like cloud computing, the merchant is accessing the power of remote software via the internet. But that’s where the similarity stops. With a triple redundant set-up, each PCI Compliant data center can operate completely independent and all are ‘hot’, meaning each are updated in real-time to mirror each other. All of the equipment is owned, not shared. This maxmimizes control over every aspect of system reliability.

Yes, there is a daily purchase limit on debit cards in addition to ATM withdrawals. This can cause a decline when a merchant tries to process a transaction over the customer daily limit. The customer may know they have the money in the bank but are not aware of purchase restrictions. Although merchants have no way of knowing reasons for a decline, if you sell big ticket items, this is something you can alert cashiers to look for.

The daily limits vary by the card issuing bank and the person issued to. For example, Wachovia Bank, a division of Wells Fargo Bank N.A. has issued cards in 2011 with a daily cash withdrawal limit of $500 and daily cash purchase of $7500. In other cases, the limits are much less.

Can you block prepaid debit cards? Yes. I regularly talk with merchants requesting a way to block prepaid debit cards, especially for installment payments.  I recently discovered I’ve been lax with my terminology though. A stored-value card is usually anonymous and there is no record of who the card belongs to or who loaded money onto it; the traditional gift card. Prepaid debit cards are usually issued in the name of individual account holders and there are records of deposits. A prepaid debit card is frequently used by students and may also have rewards programs tied to them.

In either case, they both cause problems for the merchant who has a recurring billing or an installment purchase option when there is no money left on the account and the customer already has the goods or services. One merchant told me customers will give a credit card for the down payment, but then ask to use a different card for the recurring billing. The first one will work, but the second is a prepaid or stored value card and there won’t be any money on it when it comes time to charge the account. By the time they discover there is a problem, months have passed.

The solution is to identify the card before it hits your processor. For example, if your customer opts for 3 installment payments, when you enter the card information, it is immediately validated. If you have elected to block non-credit cards for installment payments, the card will not be accepted.

New Virtual terminal web page supplements the virtual terminal blog articles in the blog. Checklist to help merchants choose the best solution without having to hunt through all the articles. I’ve created a list for you below and on the new web page.

Which Virtual Terminal features do you need?

• Basic sale, void, refund.
• Daily batch reports, transaction look up.
• Least cost routing will identify the lowest cost method to process a transaction and pass all data needed to qualify for it. This is NOT just providing the standard level II data that 99% of other virtual terminals deliver. If you’re not sure, ask. If you have corporate customers, this is HIGHLY RECOMMENDED.
• Recurring billing or installment payments. The customer pays the same amount on a fixed schedule.
• Repeat billing- your customer asks you to keep their card on file for billing purposes, but there is no set schedule or amount. Save TONS of time. After entering data one time for a client, simply enter the token ID and amount you want to charge for subsequent transactions.
• Limited user control. Create administrators and users with broad feature access.
• Maximum user control. Micro manage who can see reports, who can give refunds, set thresholds for instant email alerts by dollar amount of sale or of refund, set criteria to approve a transaction by threshold amount etc.
• Extensive real-time reports including activity by user, time of day (staff planning), facility or region, card type, general ledger item and many more. Dynamically create graphic and downloadable spreadsheet reports.
• Fees deducted from transactions or once per month?
• Do you need more than just name and card information such as assign payments to categories or general ledger codes, account numbers, or invoice numbers?
• Batch upload transaction data to process.
• Multiple bank accounts- different accounts for deposits, credits, etc.
• Integration with other systems- API connectivity.
• Multiple payment channels- a back-end that supports more than just the virtual terminal including but not limited to web payments, ecommerce and retail store.
• Always up to date with the latest parameters for interchange qualification (the wholesale cost of credit card processing).
• Least cost routing will identify the lowest cost method to process a transaction and pass all data needed to qualify for it. This is NOT just providing the standard level II data that 99% of other service providers deliver.
• Compatible with all major payment processors.
• PCI Compliant. No credit data is ever stored at your facility.

Law firms accept payments that need to be deposited into different bank accounts, depending on the purpose, such as general account and trust account. Does this mean you need two separate merchant accounts, and therefore incur the costs for two accounts?  Yes.

The main objective is to get the deposits into the correct bank accounts. This requires two merchant accounts which results in two completely different merchant statements, and their associated fees etc. What if you don’t want merchant fees to be deducted from the trust account? This can create issues for your trust account balances. This can be especially difficult for Paypal users which deducts funds from each transaction immediately, creating reconcilation challenges.

With CenPOS, our hosted payment platfom solution, and a compatible processor, you can set up to 5 different bank accounts per merchant account (MID)*. Your bank accounts will reflect exactly the correct balances you require.

For example:
Funding (credits) can be set to one bank account.
Debits (fees) to another bank account.
Disbursement of Debits (Fees, retrievals/chargebacks etc) can also be set per bank account within that one MID.

* Currently compatible with certain Paymentech and First Data merchant accounts.

Do you want to see revenue reports by attorney? Typical merchant account reports have no connection to that, however, our platform lets you set up a heirarchy so you can dynamically generate real-time reports globally across multiple merchant accounts. You can also drill down, much like an organization flow chart, to segments of the top level.

Another benefit for lawyers is TOKEN BILLING. See related article Virtual Terminal Solutions for Attorney’s.

CenPOS is compatible with swipe devices if your clients usually meet you in the office, or you can use the virtual terminal if you collect payments over the phone.

If a retail customer walks in an pays with their credit card, but the cashier made a mistake and entered the wrong amount, can the merchant go back and charge the customer the balance AFTER the customer has left the store? No. According to the Visa Card acceptance guide, “Merchants must NOT alter a sales receipt after the cardholder has signed it and left the establishment. If the cardholder has been undercharged, attempt to contact the cardholder and obtain permission to adjust the receipt so that it reflects the correct amount.”

COMMENTS:

This issue is outlined in Chargeback Reason Code 80: which includes invalid adjustment.

This question was presented by a building supply company that is largely in the wholesale B2B business, but also has some walk-in retail traffic. The consumer selected their merchandise and an invoice for the materials was issued and presented to the customer. Then the card was charged, but the amount entered was wrong.  The customer does not sign the invoice.

The merchant can research information about the transaction in their processors online transaction research, if they offer that capability. Finding the customer can be difficult, but you can try whitepages.com and hope the customer has an unusual name and is from the local area.

The merchant may not be allowed to, and should not try to, charge more than the original authorization, even if they locate the customer. The merchant or the processor may have risk management tools in place to prevent this. If the retailer locates the customer, get permission to create a new transaction which will be key-entered. In the B2B world, ideally, a note with invoice copy is faxed and the customer signs authorization to be billed the balance due. Charging a different amount than the original authorization is an automatic interchange rate downgrade.

On a final note, if the customer DID SIGN THE INVOICE then the merchant MIGHT have a basis to re-bill the customer, provided they had adequate information to do so.  Since card issuers generally side with the customer, not the merchant, if the customer disputed the bill, the merchant will likely lose. PLEASE READ THE CURRENT MERCHANT RULES for the specific card association ( MasterCard, Visa etc) for clarification.

Can I use a single merchant account if I have more than one ecommerce site? By regulation, you must have a different merchant account for each domain name.  The domain name, not the company name, must appear on consumer credit card statements. This is a field entered on the merchant application.  The main purpose is to reduce consumer confusion and thus reduce chargebacks.

What if you have single page checkouts on the same domain name?

For example, the merchant may sell something with a one page checkout. One page is mydomain.com/product1. Another is mydomain.com/product2. They do not link to a single shopping cart checkout for some internal reason. You could possibly use one merchant account for both web pages, provided it’s the same company and shares the same federal tax ID. In some cases the merchant may want to set up a separate terminal identification (TID) to assist in the reconciliation process. Each TID would have it’s own totals, but all the data appears on one merchant statement, under one merchant account. To set up TID’s, contact your merchant processor.

Non-profit organizations sometimes have this with fundraising on their web sites. The non-profit has multiple events and donor options each with a simple one page checkout specific to that event or donation. Provided the rules are met above, you can probably use one merchant account. Always check with your processor for confirmation of your situation.

related articles

internet merchant account requirements