A B2B virtual terminal that posts to your ERP
With a standalone virtual terminal, someone takes the card, and then someone keys the payment into the ERP again from the processor's report. Payment Hub's Virtual Terminal works from the ERP's own records instead, so a phone payment is applied to the invoice it pays as soon as it goes through.
- Customer and invoice lookup from the ERP. AR staff open the customer, select the open invoice or invoices, and take the payment against them, in full or in part.
- Saved cards and bank accounts. Staff can charge a card or ACH account the customer has saved as a token, without asking for the number again.
- Level 2 and Level 3 data from the invoice. Line items, tax and customer codes come from the ERP, so a phone payment on a commercial card carries the same data as a portal payment. See Level 3 credit card processing.
- One posting path. Phone, mail and email orders post to the ERP the same way as counter and customer portal payments.
- Staff roles. Each user gets the access their role needs, location by location.
Basics of a Virtual Credit Card Terminal
A virtual terminal, also known as an online payment form, is a web-based software that allows you to accept electronic or digital payments by phone, internet purchase, mail order, fax, email, or in person.
For in-person payments, you’ll use a card reader that’s connected to a computer via a USB. For other methods, you’ll need an internet connection and a web browser.
How Does a Virtual Terminal Work?
It's quite simple to get started with a virtual terminal. You will, depending on your merchant account provider:
- Open a virtual terminal on your computer or smartphone by logging into an online dashboard or B2B payment gateway.
- Select the payment method: Credit/debit or eCheck/ACH transaction.
- Fill in the sales amount, and any other order notes.
- Fill in the card number or bank account information on the internet form, as well as any billing data required.
- Click the Submit Transaction button to finalize your purchase.
Confirmation is sent that the card has been accepted or rejected. If approved, most virtual terminals provide clients the option of sending them a copy of their receipt.
Issue Refunds & View History
In addition to executing payments within the virtual terminal, you can also issue refunds and view your transaction history.
When conducting a card-not-present (CNP) transaction, it's important to keep in mind that phone and mail orders, for example, often cost more because of the additional security risks. You must trust that the individual providing the account information is indeed the cardholder.
In a CNP transaction, whether you key in data yourself or let the customer do it manually, the sale is considered a card-not-present transaction, even if the client is standing in front of you.
Consider accepting ACH payments or eCheck as well as credit and debit cards to minimize your transaction processing costs when using a virtual payment processing terminal. This form of electronic payment usually costs less than traditional card transactions. For commercial cards, the data you send matters more than whether the card is present: on Visa's schedule effective April 18, 2026, Commercial Product 3 (full Level 3 data) is 1.75% + $0.10, below the card-present rate of 2.50% + $0.10.
Tokenization and End-to-End Encryption
Virtual terminal transactions are processed through a payment gateway, which can enable tokenization technology and end-to-end encryption to safeguard sensitive data while moving it through your payments system.
When a consumer gives their payment information, the primary account number (PAN) is replaced with a randomly generated alphanumeric ID, known as a “token,” that is only meaningful to the B2B payment platform processor.
Because the token stands in for the card number, you no longer have to store sensitive information on your system, thereby vastly reducing the possibility for a security breach. That can reduce your PCI scope, depending on how the payment page is set up, though it doesn't remove your PCI obligations. The tokenized data is then transformed before being sent to the payment processor, which will route the transaction via the card payments network.
Working out how this fits your setup?
Tell us how you take payments today and which gateway and ERP you run. We'll walk through what Payment Hub would change end-to-end, against a sandbox of your own system.
Levels 2 and 3 Processing
Interchange rates are set by the card networks and paid to the card-issuing bank on every transaction. These costs are determined by a variety of criteria, including whether the card was present and whether it was swiped, dipped, or hand keyed. On commercial cards, the more line-item data you send, the lower the rate can be.
Consider adding Levels 2 or 3 payment processing for your clients if you accept B2B or B2G transactions. These sorts of credit card processing methods include more data, such as customer codes, tax amounts, and tax identifications, to help you reduce interchange costs and accommodate your B2B and B2G customers more efficiently.
Payment Hub's virtual terminal pulls that data from the ERP invoice, so phone payments can qualify too. Level 3 credit card processing covers what Visa's 2026 rules changed.
Fraud Management Tools
A virtual terminal is used by a large number of firms to process phone or email purchases, making those CNP transactions. Because these are not in-person transactions, fraud tools such as address verification service (AVS), card verification value (CVV), card identification number (CID), or two-factor authentication (2FA) help verify the customer's identity.
- You can request a billing address in order to compare it to what the card-issuing bank has on file with AVS. You have the option of verifying against complete addresses or zip code comparisons.
- The 3-digit code on the back of the card, or the 4-digit code on the front of the card, can be requested to determine if a genuine card is being presented for payment versus a stolen credit card number when using CVV/CID.
- Customer-initiated electronic payments are verified using two factors that are linked together, such as a user receiving a text message to their registered phone to confirm that they are the real account holder.
The virtual terminal in your ERP
Phone payments land on different records in each ERP. Here is what that looks like in each one:
- Epicor Eclipse payment processing: contractors calling in a card against branch job-account invoices.
- Epicor Prophet 21 payment processing: plant buyers reading a P-card number over the phone for an MRO order.
- Epicor Eagle payment processing: a card called in against a contractor's store charge account, posted as the ROA.
- Epicor Kinetic payment processing: keyed payments against Kinetic invoices for each company and plant.
- Epicor E10 payment processing: phone payments applied to ARInvoice balances instead of rekeyed from a report.
- Infor SyteLine payment processing: phone payments on customer order and project invoices.
- SYSPRO payment processing: keyed payments posted as AR receipts in the right SYSPRO Company.
- Sage 100 payment processing: phone payments posted as AR cash receipts, whichever gateway you use.
- NetSuite payment processing: a card taken during the call, from inside NetSuite.
- Sage Intacct payment processing: keyed payments applied per entity and contract.
- Acumatica payment processing: phone payments against Acumatica invoices, branch by branch.
- Business Central payment processing: a card taken during the call, from inside Business Central.
- Dynamics GP payment processing: phone payments posted as GP cash receipts, ready for your move off GP.
- Dynamics 365 Finance payment processing: shared service center phone payments posted per legal entity, not keyed from the next morning's report.
- Odoo payment processing: keyed payments reconciled against Odoo invoices.
- Sage 300 payment processing: phone payments in each company's currency, posted as AR receipts.
- Sage X3 payment processing: keyed payments per site and legislation.
- SAP Business One payment processing: a card called in against an A/R invoice or a down payment invoice.
- SAP S/4HANA payment processing: phone payments on open items for each Company Code.
- Dynamics NAV payment processing: keyed payments on open customer ledger entries in NAV.
All 25 ERP integrations are on the Payment Hub integrations page.