National payment workflow guide

Virtual Terminals, Invoicing & Payment Links

These tools can all support remote payments, but they assign different actions to staff and customers. Compare the journey, records, security boundaries, reporting, and exception handling before choosing a workflow.

Three distinct workflows

Start with who enters the payment information

The clearest distinction is the handoff. A virtual terminal is generally operated by the merchant, while an invoice or payment link commonly gives the customer a provider-hosted path to review information and submit payment. Exact features and responsibilities vary by provider.

Virtual terminal

PCI SSC defines a virtual payment terminal as browser-based access to an acquirer, processor, or service provider site where a merchant manually enters payment card data. It is not a physical card-reading device.

Digital invoice

An invoice connects a request for payment to a named customer, described goods or services, an amount, terms, and an account record. Some systems add hosted payment, reminders, status tracking, or partial-payment tools.

Payment link

A payment link sends a customer to a hosted checkout. Depending on the provider and configuration, a link may represent a specific item, a fixed or customer-entered amount, an event, a donation, or another supported checkout.

Connected workflow

A business may use more than one method, but every transaction should have a clear source, customer reference, status, receipt path, refund process, and owner for follow-up.

Responsibility boundary: Provider features, payment methods, security scope, transaction indicators, record retention, and customer-notice requirements differ. Confirm the current setup with the responsible acquirer or payment provider and qualified advisers.

Decision path

Match the tool to the interaction

Is a staff member taking the payment?

A provider-supported virtual terminal may fit a staff-assisted phone or mail-order workflow. Define how staff authenticate, where they receive information, what they may write down, and how they avoid copying sensitive details into email, chat, notes, or tickets.

Does the customer need a detailed request?

An invoice can organize the customer, line items or service description, amount, dates, terms, communications, and payment status. Review how edits, reminders, deposits, partial payments, credits, and cancellations appear in records.

Does the customer need a simple checkout path?

A payment link may reduce the steps needed to collect payment without building a full ecommerce cart. Check whether the link is reusable or transaction-specific, how the amount is set, what the customer sees, and when the link expires or is disabled.

Is the sale already managed elsewhere?

If a CRM, booking tool, field-service platform, accounting system, or order system owns the customer record, define which system creates the request and which one receives payment status. Avoid duplicate records with conflicting balances.

Evaluation checklist

Compare the complete operating model

Customer context

Identify what the customer sees before paying: business identity, description, amount, contact path, applicable policies, reference number, and a way to recognize the final receipt.

Staff permissions

Separate creation, editing, payment entry, refunds, voids, exports, and account administration. Review shared logins, former staff, temporary access, and approval steps.

Data handling

Map every place payment information could enter or remain, including browsers, paper, call recordings, email, support systems, screenshots, exports, logs, integrations, and backups.

Record matching

Choose the customer, invoice, order, job, or booking reference that follows the transaction into receipts, provider reports, deposits, refunds, disputes, and accounting records.

Customer communication

Review sender identity, link domain, delivery method, reminders, receipt content, failed-payment messages, and the process for customers who question whether a request is genuine.

Lifecycle controls

Document when a request becomes active, who may change it, whether the same link can be reused, how it is canceled, and what happens to unpaid or partially paid records.

Safe operations

Keep sensitive details out of general business channels

Use the intended payment screen

Enter information only through the provider-supported flow. Do not redirect complete card details into ordinary forms, email, messaging, spreadsheets, CRM notes, or support tickets.

Protect the staff device

For virtual-terminal use, review device access, updates, browser hygiene, network protections, session timeout, and the surrounding workspace. PCI SSC guidance treats the merchant device and process as important parts of the scenario.

Verify requests before changing them

Use an authenticated process for amount changes, customer-detail updates, bank or account changes, refunds, and link replacement. Preserve a non-sensitive audit trail of who acted and when.

Plan for suspicious messages

Tell customers how to verify an invoice or payment link using a known contact path. Staff should know how to disable a questionable request and escalate possible account compromise.

Exceptions and reconciliation

Design the workflow beyond successful checkout

Duplicate or uncertain status

Before trying again, check the provider result, customer record, request status, and transaction history. A browser interruption does not by itself prove that a payment failed.

Changed amount or scope

Decide whether staff edit the original request, issue a replacement, add a separate request, or document an offline adjustment. Keep the customer-facing and accounting records aligned.

Refund, void, or cancellation

Identify which action applies to the transaction state and who is authorized to perform it. Connect the result to the original reference and customer communication.

Deposit reconciliation

Trace each payment from its originating invoice, link, or staff entry through the provider report and deposit. Record exceptions without storing complete payment credentials.

Provider questions

Confirm capabilities and ownership

Setup and scope

Which workflows are supported for the business type, and which systems, devices, networks, and procedures remain the merchant's responsibility?

Checkout and records

What information can customers review, what references appear in reports, and how do receipts, reminders, edits, expirations, and partial payments behave?

Access and response

Which roles and authentication options are available, where activity is logged, and what is the response path for suspicious access or an incorrectly sent request?

Integration and exit

How are statuses synchronized with other systems, what can be exported, and what happens to active links, unpaid invoices, records, and user access when service changes?

Common questions

Virtual terminal, invoice, and payment link FAQ

Is a virtual terminal the same as a payment link?

No. PCI SSC describes a virtual terminal as a browser-based provider page where the merchant manually enters card data. A payment link generally directs the customer to a hosted checkout.

Is an invoice just a payment link?

Not necessarily. An invoice normally carries customer and billing context, while a link is a checkout path. Some invoice systems include a hosted payment link, but records and available features vary.

Can one payment link be sent to multiple customers?

Some providers support reusable links and others support request-specific links. Confirm amount controls, customer identification, reporting, expiration, and duplicate-payment handling before reuse.

What should staff record after a phone payment?

Keep a non-sensitive customer or order reference, timestamp, authorized amount, provider result, receipt path, and staff audit record. Do not copy complete payment credentials into general business systems.

Last editorial review: August 11, 2026. Sources reviewed: PCI SSC virtual-terminal definitions and small-merchant guidance, plus current official Stripe and Square documentation illustrating invoice and payment-link workflows whose features vary by provider.

Next step

Map your remote payment journey

Payments Max can help organize customer handoffs, staff actions, systems, records, security boundaries, reporting, and support questions before you compare available options.

Contact Payments Max

To learn more about how TSYS can help improve the way your organization accepts payments, markets to new customers, or manages its HR responsibilities, get in touch by calling 585-981-8463 to get started.

CONTACT US