Virtual payment systems

Virtual payment systems — virtual terminal on the same orchestration as web.

topropay's virtual terminal lets authorised operators take card-not-present authorisations from a dashboard surface — phone, mail and B2B-quote flows — with every authorisation routed across the connected acquirer panel and reconciled into the same ledger as web and mobile traffic.

Book a virtual-terminal review Read the API docs
topropay.com/dashboard/virtual-terminal
MOTO authorisation entry-mode: virtual-terminal

routed via topropay · acq C selected · 184ms

MOTO
phone / mail / virtual-terminal flows
Many
connected acquirers behind one panel
<200ms
routing decision per authorisation
1 ledger
across virtual and web traffic

Key benefits

Why orchestrated virtual payment processing wins on operator-side flows

Four outcomes that show up consistently once virtual-terminal traffic runs through the same orchestration layer as web and mobile — rather than living on a separate console with its own pipeline.

  1. 01

    A virtual terminal that authorises across many acquirers

    topropay's virtual terminal is a dashboard surface for operator-side card-not-present authorisations — used for phone, mail-order and offline-quote scenarios. Each authorisation runs through the same routing engine as the web checkout, so the cascading and acquirer-selection benefits apply to virtual-terminal traffic too.

  2. 02

    Virtual payment processing on the same API as web

    Virtual payment processing and web payment processing share the same /v1/payments endpoint, the same vault, the same reconciliation feed. The distinction is the entry-mode flag (MOTO / virtual-terminal vs CIT vs MIT) — the rest of the lifecycle is identical.

  3. 03

    Operator-side controls with full audit trail

    Every virtual-terminal authorisation logs the operator identity, timestamp, reason code and customer reference. The audit log is surfaceable for compliance reviews; refunds and voids run through the same operator surface with the same audit retention.

  4. 04

    One reconciliation feed across virtual and online traffic

    Virtual-terminal authorisations, web checkout receipts, mobile pay-sheet captures and bank-rail debits roll into one ledger keyed off vault tokens. Finance closes the month from one export — and the ledger tags every row with the entry mode, acquirer and operator (where applicable).

How it works

From operator login to a normalised ledger entry in five stages

Five concrete stages between an operator opening the virtual terminal and the row settling into the reconciliation export.

  1. 01

    Operator opens the virtual terminal

    Operators log into the dashboard with role-scoped permissions. The virtual-terminal surface exposes amount, currency, descriptor, customer reference and card-entry fields — with the merchant's preferred descriptor and currency pre-filled.

  2. 02

    Card data captures into the vault

    Card fields are rendered as hosted iframes; PAN data captures into the PCI DSS Level 1 vault before the operator surface ever touches it. The operator never sees the full PAN after the field is filled — masked display only.

  3. 03

    Authorisation runs through the routing engine

    The MOTO / virtual-terminal authorisation runs through the same routing engine as web traffic — scored on BIN, scheme, currency, country pair and risk signals across the connected acquirer panel. Soft declines cascade.

  4. 04

    Result returns to the operator

    Approved / declined / 3DS-required result returns inside the operator UI within seconds. The operator can capture, partially capture, refund or void via the same screen — every action logged with operator identity.

  5. 05

    Receipt rolls into the unified ledger

    The authorisation, settlement and any fee adjustment appear in the same normalised export as web and mobile receipts — daily, signed, with the entry-mode tag for downstream reporting.

Main use cases

Where virtual payment platform flows earn their keep

Six merchant shapes that lean on the virtual terminal as either the primary or a complementary surface — phone-orders, travel desks, B2B sales, subscription rescue, service businesses and web-checkout backup.

  • Phone

    Phone-orders and call-centre teams

    Call-centre operators take card details over the phone and authorise inside the virtual terminal — without the merchant's PBX or CRM ever touching PAN data. The hosted-iframe surface keeps PCI scope on the platform side.

  • Travel

    Travel and hospitality desks

    Hotel front-desk teams, travel agents and ticket-office operators handle bookings, deposits and final payments through one virtual-payment-platform surface. Staged captures and partial refunds run from the same screen.

  • B2B

    B2B invoicing and quote acceptance

    B2B sales teams authorise card payments against a quote via the virtual payment gateway — useful when the buyer wants to pay by card but the merchant's commerce flow is offline-quote-driven. The invoice and the authorisation share one reference.

  • Subs

    Subscription operations and rescue

    Subscription-ops teams take rescue payments from customers whose card has lapsed — the operator captures fresh card details into the vault, the customer's subscription gets a new vault token, and renewal cycles continue.

  • Service

    Service businesses without a storefront

    Consultants, agencies and service businesses without an online checkout use the virtual terminal as their entire payment surface — authorise on a per-engagement basis, refund through the same screen, reconcile in the same export as any other merchant.

  • Backup

    Backup channel when web checkout is down

    If the merchant's web checkout itself is unavailable, the virtual terminal stays online — operator-side authorisations can absorb the order flow until the web surface is back.

Platform features

Capabilities behind virtual merchant payment gateway flows

What the platform actually ships for the virtual-terminal surface — beyond the general orchestration features shared with web and mobile traffic.

  • Virtual terminal

    Dashboard surface for operator-side card-not-present authorisations; role-scoped access; hosted-iframe card fields; per-action audit log.

  • Same unified API as web

    Virtual-payment authorisations POST to the same /v1/payments endpoint — different entry-mode flag, same response shape.

  • Smart routing engine

    Per-transaction scoring on BIN, scheme, currency, country pair and risk — applied to virtual-terminal traffic identically to web.

  • Cascade & retry

    Soft declines cascade to the next ranked acquirer inside the same authorisation; the operator sees one final result.

  • PCI DSS Level 1 vault

    Card data captures into our vault before any merchant origin touches it; the operator surface never sees the full PAN.

  • Per-operator audit log

    Every virtual-terminal action logs operator identity, timestamp, reason code and customer reference — surfaceable for compliance.

  • 3DS / MOTO entry-mode handling

    Selective 3DS challenges where applicable; MOTO entry-mode flagged on the authorisation per scheme rules.

  • Captures, refunds, voids

    Full lifecycle (capture, partial capture, refund, partial refund, void) inside the virtual-terminal surface.

  • Customer-reference field

    Customer reference / order ID carried on every authorisation for downstream reporting and dispute response.

  • Operator portal

    One dashboard for virtual-terminal, web and mobile authorisations, refunds, disputes and chargebacks — across every connected acquirer.

  • Reporting & exports

    Per-operator, per-entry-mode and per-acquirer roll-ups in the dashboard and the daily reconciliation feed.

  • Sandbox parity

    Sandbox tenant supports the full virtual-terminal flow — including 3DS challenge simulation and decline-reason testing.

Trust & compliance

Compliance posture for virtual payment processing

The virtual terminal inherits the platform's audited environment. PCI scope sits with topropay; operator actions are logged with full audit retention.

PCI DSS Level 1
Annual on-site assessment plus quarterly ASV scans; the virtual terminal inherits the same posture as the web surface.
Hosted-iframe card fields
PAN data is never typed into the merchant operator's machine in raw form — it captures directly into the platform's vault via hosted iframes.
Role-scoped operator access
Operator accounts carry role-scoped permissions (capture, refund, void, view-only); operator actions log identity, timestamp and reason code.
MOTO compliance flagging
MOTO / virtual-terminal entry mode is flagged on the authorisation per scheme rules; interchange treatment follows the relevant scheme tier.
Sanctions & AML alignment
Sanctions screening on onboarding; AML monitoring tuned per merchant vertical, volume and entry-mode mix.
Licensed verticals only
Licensed gaming, regulated financial services and other compliance-bound verticals supported only where current operating licences exist. Grey and black-market verticals are out of scope regardless of integration shape.

Ready to give operators the keys

Virtual terminal plus the same orchestration as web.

A 30-minute virtual-terminal review covers the operator-side surface, role-scoped permissions, the routing policies that fit MOTO traffic and a sandbox to test against before any commercial commitment.

Book a virtual-terminal review Read the API docs

Frequently asked

Buyer questions about virtual payment systems on topropay

Questions buyers ask before committing — virtual-terminal specifics, MOTO compliance, virtual-merchant model, pricing, audit logging and how virtual flows roll into the unified reconciliation feed.

  1. 01

    What does topropay mean by virtual payment systems?

    Virtual payment systems on topropay is the umbrella for non-web card-not-present authorisations — typically operator-driven flows: a phone-order, a mail-order, a B2B quote, a hotel front-desk booking. The virtual terminal is the operator surface; the back-end is the same orchestration layer that powers web and mobile traffic.

  2. 02

    What is a virtual terminal exactly?

    A virtual terminal is a web-based dashboard surface where authorised operators authorise card payments on behalf of customers, typically when the customer isn't initiating the payment from their own device (phone, mail, in-person at a service desk). topropay's virtual terminal is integrated with the same routing engine and vault as the web API.

  3. 03

    How is virtual terminal payment processing different from regular web payment processing?

    Virtual terminal payment processing flags the authorisation as MOTO (mail-order / telephone-order) per scheme rules — the entry mode differs from a customer-initiated web transaction. Interchange treatment and dispute defaults follow the MOTO category. The underlying routing, vault and reconciliation are identical.

  4. 04

    How does virtual payment processing through topropay handle PCI scope?

    Virtual payment processing keeps PCI scope on the platform side. The operator's machine never holds PAN data — the card-entry fields are rendered as hosted iframes inside the virtual terminal, and the card captures directly into the platform's PCI DSS Level 1 vault. The merchant inherits the service-provider posture rather than carrying it themselves.

  5. 05

    What's the difference between a virtual terminal payment gateway and a regular gateway?

    A virtual terminal payment gateway exposes the gateway behaviour through an operator UI rather than a customer-facing checkout. The authorise / capture / refund / void verbs are the same; the entry mode and the operator-audit-log requirements differ. topropay collapses both shapes behind one API and one operator portal.

  6. 06

    Is the virtual payment gateway separate from the web payment gateway?

    No — the virtual payment gateway and the web payment gateway are the same underlying engine on topropay, with different entry modes flagged per authorisation. From the merchant's billing system and reconciliation feed, they look like one traffic stream with an entry-mode column.

  7. 07

    What virtual payment solutions does the platform expose beyond the virtual terminal?

    Beyond the virtual terminal itself, virtual payment solutions include the dashboard refund / void surface, the operator portal for chargeback evidence, the per-operator audit log, the customer-reference tagging on every authorisation, and a hosted-payment-link surface (for buyers who'd rather pay via a one-off link than have an operator take card details over the phone).

  8. 08

    What's the virtual merchant model on topropay?

    Virtual merchant on topropay refers to a merchant that authorises card payments primarily through operator-side flows rather than a public e-commerce checkout — service businesses, agencies, B2B sales teams, call centres. The same sub-merchant onboarding applies; the merchant uses the virtual terminal and the operator portal as their entire surface.

  9. 09

    Is a virtual merchant payment gateway the right shape for an early-stage business?

    A virtual merchant payment gateway is often the right shape for an early-stage service business that doesn't yet have an online checkout — operators can take payments from day one through the virtual terminal, and the merchant adds web / mobile surfaces later through the same API when the product surface justifies them.

  10. 10

    What does the virtual payment platform support for recurring billing?

    The virtual payment platform handles recurring billing the same way the web side does — first authorisation captures into the vault, subsequent renewals run as merchant-initiated transactions (MIT) against the vault token. Operators can authorise rescue payments through the virtual terminal when a renewal lapses; the new card credential takes over the recurring cycle.

  11. 11

    How is virtual payment processing priced?

    Virtual payment processing pricing is per-authorisation on top of underlying acquirer economics — same model as the web side. MOTO interchange typically carries a different rate from CIT card-not-present (set by the schemes); that rate passes through transparently on the invoice.

  12. 12

    Can the virtual terminal be restricted to specific operators?

    Yes. Operator accounts on the virtual terminal carry role-scoped permissions — capture, refund, void, view-only — and IP allow-list restrictions where the merchant requires them. Every action logs operator identity, timestamp and reason code. The audit log is surfaceable for compliance reviews.

  13. 13

    Are there compliance considerations specific to MOTO virtual payments?

    MOTO virtual payments carry specific compliance considerations: the operator must not store card details outside the platform's vault, the audit log must capture every action with operator identity, and the entry mode must be flagged on the authorisation per scheme rules. topropay's virtual terminal handles all three by design.

  14. 14

    How does a virtual payment platform handle disputes differently from web?

    Dispute defaults differ for MOTO authorisations — the burden of proof on representment is higher because there's no 3DS challenge in the typical MOTO flow. topropay surfaces this in the dispute queue with MOTO-specific evidence-pack templates (customer-reference, operator identity, timestamped notes) to make representment as well-evidenced as possible.

  15. 15

    Can a merchant run only the virtual terminal without a web checkout?

    Yes. Many service-business merchants run only the virtual terminal — the operator portal is their entire surface. Adding a web checkout later is a configuration step on the same merchant contract, not a re-integration.

Related

Related on the topropay platform