I frequently receive inquires about the details of how payments are handled between eCommerce platforms and Acumatica. Below are details about this topic.
Common eCommerce Merchant Profiles
We see 2 primary types of Merchants who are selling via eCommerce and managing their back office via Acumatica.
- B2C/D2C Merchants
- Often, individual orders are small.
- B2C/D2C merchants rarely sell items which cost more than $2k
- Most Consumer purchases are done with a CC
- Sometimes merchants allow buyers to place an order, pickup/pay in store
- B2B Merchants
- Orders are typically larger
- Common to see orders which total at $5k - $30k
- Some buyers want to use CC for payment, or it's a requirement of the seller
- Many buyers will prefer to pay by check via NET30/NET45 Terms
Rule of Thumb - best to not try to guess at how merchants will want to handle payments. Every merchant is different, and it's not an area where they are flexible. Goal is to make the technology as flexible/extendable as possible to accommodate their needs.
Resource - Acumatica Help Documentation related to Accounts Receivable -
Types of ERP Payments
- Credit Card/Debit Card payments are processed in 2 steps
- Authorize - authorize the card for the specified amount of money. No money is transferred, but the processor ensures the correct money is available and they put that money on a temporary hold until the funds are captured.
- Capture - process of actually moving the buyers funds to the merchant
- Within eCommerce platforms you can configure "Automatic" payments (does Auth and Capture at the same time) or "Manual" payments (authorizes now, merchant manually triggers the capture of funds)
- This is common with B2B Merchants and some B2C/D2C sellers
- The merchants want to capture funds within the ERP
Pay by Check
- B2B merchants build strong relationships with their customers
- These relationships lead to unique payment scenarios with each customer
- Often, B2B merchants extend "Credit" to their buyers. Especially frequent or high dollar customers.
- B2B merchants typically configure different levels of "Credit" and payment terms. These are organized into "Customer Classes" which is essentially a category. Each customer assigned to one of these "Classes".d
- Examples of Classes
- Brand new customer - No credit extended. No Terms. Customer must pay by CC
- Good customer, small volume - Can pay by CC. Also extended $XX,XXX in credit and Net30 terms. Meaning, the buyer can purchase up to $XX,XXX in goods and then be invoiced for the purchases with 30 day payment terms.
- $XX,XXX = what is appropriate for the industry and merchant
- Great customer, high volume/dollar - Can pay by CC. Also extended $YY,YYY in credit and Net60 terms. Meaning, the buyer can purchase up to $YY,YYY in goods and then be invoiced for the purchases with 60 day payment terms.
- $YY,YYY = what is appropriate for the industry and merchant. Also, this is typically a higher amount than Class "Good Customer" because the relationship is strong
- When paying open invoices which have used Account Terms/Credit there are a few "rules".
- Buyers typically wait till they have several open invoices, waiting to the last minute to pay. OR, they pay down if they are close to crossing their Terms limit (example - have $10k in credit, and have spent $9k. Time to pay it down)
- When ready, the buyer wants to pay multiple invoices at the same time
- Acumatica allows buyers to pay per line within invoices. (https://help.acumatica.com/(W(1))/Help?ScreenId=ShowWiki&pageid=1429694d-15cc-428a-948e-fc7b71bbf78c)
- Sometimes the open invoices are paid by check. Sometimes paid by CC
- Even if the merchant required a CC Auth on the website, they have the option to allow buyers to complete the payment via check. In this case, the CC Auth is a (weak) form of collateral (AKA - we want to make sure you have the money)
- Examples of Classes
Cash (for POS merchants)
- Accepting cash is also possible
- The cash is typically retreived by the merchant in person (typically in Retail Store or a B2B Showroom)
- Within the POS the Cash Transaction takes place and this is recorded to a Cash Payment Method and Cash Account in the ERP
When are funds captured?
Technically, merchants are not supposed to capture payments until they ship their buyers order. Not 100% of merchants abide by this rule, but we must provide software which will support what is required. Below are several payment related scenarios including instances when a shipment may be split or delayed which impacts CC authorizations.
Merchant Payment Scenarios
Purchase with Terms
Buy online, don't pay anything today, once the order is in Acumatica we'll send you an invoice. Buyers are expected to pay within the requirements of their Terms agreement. Sometimes paid by check or via CC transaction.
Authorize and Capture during eCommerce checkout
Many B2C/D2C Merchants ship their products within 24 hours of receiving orders (or within a reasonable amount of time) so they simply Authorize and Capture at the time of submitting checkout on the eComm platform.
- B2C - I'd say 80%+ B2C simply capture at checkout
- B2B - used with Brand new customers or guest customers. Especially when the merchant is confident items will ship quickly.
How it's solved
In this case, any payment gateway provided by the eCommerce platform can be used. Funds are captured in the eComm site. A reference to the payment is sent into Acumatica and the payment is associated with a specific Payment Method in the ERP. Majority of our customers use this. Especially B2C merchants
Auth on eComm, Capture in ERP (Personalized items, back orders)
In some cases, the merchant must prepare the product before shipping, or they must wait till the items are back in stock before shipping.
Imagine a personalized item. Consumer buys it, the merchant must prepare it (which can take 1+ week) then they ship it. An example is a custom tshirt printer, or a merchant who engraves goods with custom designs.
- B2C who sell personalized/configured items (Jewelry, personalized goods, some furniture/home goods)
- B2B - This is often a requirement of B2B merchants
Auth on eComm, Capture multiple times in the ERP (Split Shipments)
In this scenario, an order comes in with (let's say) 3 line items. The merchant can ship 2 line items today, but the 3rd item needs to be prepared and will not ship until three weeks from today.
In this case, the merchant will capture the funds for the first 2 line items. This will close out the current payment authorization. When it's time to ship the 3rd line item they will need to Authorize and Capture the funds for the 3rd line item.
Some merchants will simply capture 100% of the funds with the first shipment, but this is not the proper process and often if high volume brands do this their customers complain.
- B2C - nearly all merchants face some split shipment situations. Sometimes the order must be fulfilled by different warehouses, 3PLs or Drop Ship vendors. Also, merchants want to ship what they have immediately.
- B2B - This is very common with B2B merchants. Sometimes it is due to inventory levels, production timelines, ship via different warehouses. Imagine an order with 100 line items. It's common for 75% to be ready to ship today, but the other 25% to need to ship later. Happens all the time.
Auth on eComm/Capture much later in ERP (Back Order, Seasonal, Pre Order)
In this case, the items are bought today, but the merchant and the buyer understand that they won't be shipped for many months. You see this with seasonal companies (holiday companies, nurseries, building supply or landscaping companies, made to order, etc)
- B2C - Not super common in B2C unless it's a particular industry/brand. Imagine a brand taking pre-orders on a new product line. They will sell online, know the exact number of products needed, then go into production and ship the items many months later.
- We also see this with Landscape companies and Nurseries. Buy your plants today, they ship when it's the right season to plant them.
- B2B - This is more common with B2B merchants. In some cases it's the industry (Landscaping companies, etc) and other times it's desired by the buyer. Imagine a construction company that is buying building supplies for a job. That job will go on for 12 months. The Project Manager knows all the supplies they'll need, but they need to schedule when each item will ship. AKA, "I don't need my roofing supplies here on my jobsite next week. First, we need materials to lay the foundation."
Challenge - capturing a 2nd payment or capturing payment after the authorization has expired
Challenge - In some cases, merchant's can't ship a buyer's good until weeks after the initial Authorization of the Credit Card. Examples of these scenarios are listed above (Personalized Items, Split Shipments, Back Orders, Seasonal Items).
There are 2 challenges which could arise in this situation
- Eventually the initial authorization of the credit card payment could expire if not captured, usually within 7-10 days. In this case, the CC has to be Authorized again, then captured.
- The merchant may ship a fraction of the order today and capture a fraction of the funds. When it's time to ship the rest of the items, the merchant will need to capture the rest of the funds. The initial capture would have canceled the Authorization, so the merchant must re-authorize/capture the funds.
- Merchants do not want to call the customer for their payment information. This is a waste of time and it creates a poor customer experience.
- The solution is to collect and store a Credit Card token with the buyer's account. This token represents the customer's credit card and can be used to initiate authorizations and captures. When the funds are needed, that token is used to initiate an Auth/Capture.
Requirements to accomplish this
- To accomplish this, it's required for the Payment Gateway to be integrated with Acumatica. Acumatica has built integrations with Authorize.net and Stripe to accomplish this.
- Within the Acumatica ecosystem, several partners have built additional payment integrations. Learn more at acumatica.com/marketplace
- Additionally, when buyers are checking out on the eCommerce platform, the checkout page can include a checkbox for "Save my CC to my account". This box is required to be checked to allow the card's token to be saved.
- Some merchants are fearful that buyer's will not check this box and they'll be stuck calling the buyer for the CC information.
- To overcome this, some agencies will check the box by default and/or check the box and hide the feature (which forces the capture of the CC token). Obviously, the decision to do this is a business decision each merchant must make.
Once the ERP has the customer's CC token, it can be used for future Authorizations and Captures. This can be beneficial for example situations listed above in which the original Authorization has expired and/or situations where 2 captures are necessary (like split shipments).
NOTE - We do not store any CC numbers or CC information in any of our databases. This is a strict rule. We only store the CC token, which is encrypted and secure. That token is used to initiate captures.
- Authorize on eCommerce, Capture in the ERP - this is supported with Authorize.net, Stripe and Shopify Payments today. Additionally, within our ecosystem other partners have built similar solutions.
- This will work with BigCommerce today without any issues.
- Shopify doesn’t accept payment updates from external systems however. Though you could authorize on a Shopify site, then capture in the ERP, we can not (technically) send the payment update back to Shopify. Hence, there’d have to be a manual step to update this information inside Shopify. We’ve notified Shopify of this use case and their Payments team explained that they are aware of this challenge/desire from merchants and are intending to build a solution in the future.
- Save CC to Customer Account for future payments - this is supported with Authorize.net and Stripe today. Additionally, within our ecosystem other partners have built similar solutions.
- This will work with BigCommerce today, no problem.
- However, Shopify does not allow payment tokens to be exported outside of Shopify to other external systems. Just as above, we have notified the Shopify Payments team of this use case and they are aware of this need.