Skip to content
elasticpay

Virtual Terminal

Channels: Embedded (internal page) · Direct Methods: Card · BECS (saved methods only)

A virtual terminal is a payment your staff initiate — a phone order, an invoice paid over the counter, a service business charging after the work is done. The customer isn’t on your website; your operator is.

The golden rule

Even internally, never key card numbers into your own forms, CRMs, or spreadsheets — that puts your business in full PCI scope. The safe patterns below keep card data inside ElasticPay-controlled surfaces.

Pattern A — Internal page with the embedded widget

Build a simple internal page (behind your staff login) that embeds the widget. Your operator:

  1. Creates the payment intent (your page calls your server, which calls the API with the amount)
  2. Keys the card details the customer reads out into the widget — the details are tokenised inside the ElasticPay frame and never touch your systems
  3. Confirms — the result shows on the page and the webhook closes it out

This pattern is card-only. A BECS mandate must be accepted by the customer — the acceptance evidence records who agreed to the Direct Debit Request, so staff can’t key bank details on a customer’s behalf. To take BECS from a virtual-terminal context, use Pattern B against an existing mandate, or have the customer complete the BECS widget flow themselves.

Pattern B — Charge a saved method

For repeat phone customers, save the method once (Pattern A plus customer_id, or a Setup Intent), then each subsequent order is just charging the saved method — no card details read out over the phone at all. This is also the only way BECS works here: once the customer has accepted a direct debit mandate, your staff can charge it like any saved method.

Pattern C — Send the customer a payment link

If the customer can use a browser mid-call, create the intent and send them into the hosted payment page — they enter their own details, and you watch for the webhook.