Choosing a Channel

A channel is how payment details get from your customer to ElasticPay. All three channels produce the same thing — a tokenised payment method (pm_xxx) confirmed against a payment intent — so your server-side integration is identical whichever you choose.

The three channels

Channel	You build	Best for
Hosted payment page	A form POST redirect	Fastest integration; no front-end work
Embedded widget	A container element + a few lines of JS	Keeping customers on your page
Direct API	Server-to-server calls with tokens	Back-office flows, custom architectures

PCI implications

The channel determines how card data flows, which determines your PCI scope:

Channel	Card data touches	Your PCI scope
Hosted payment page	Never your site — customer pays on an ElasticPay page	SAQ A
Embedded widget	An ElasticPay-controlled frame inside your page — never your DOM or servers	SAQ A
Direct API	Never — you only handle pm_xxx tokens	Tokens are not card data

“Embedded” here means something precise: the widget renders card inputs inside an ElasticPay-controlled frame. Your page hosts the frame but can never read the card number. That boundary is what keeps you at SAQ A — see Security & PCI Compliance.

Caution

Never build your own card form and post card numbers to your server or ours. That single decision moves you into full PCI DSS scope.

Method support by channel

Channel	Card	BECS Direct Debit
Hosted payment page	✅	— (use the BECS widget or direct API)
Embedded widget	✅ ElasticPayCardWidget	✅ ElasticPayBecsWidget
Direct API	✅ (tokenised pm_xxx only)	✅

Choosing

• Just want to get paid? Start with the hosted payment page.
• Want the payment form on your own page? Use the embedded widget.
• Charging saved methods, back-office initiation, or building your own UI around tokens? Use the direct API.

Whichever you pick, start from your use case — it tells you which channel and method combination fits.