Barclaycard withdrew the ePDQ platform on 31 March 2026 — the hosted payment pages, the e-Terminal your staff keyed phone payments into, and the DirectLink API behind integrated checkouts. If you are still choosing its replacement, every ePDQ flow has a direct felloh equivalent — and the move is a chance to shift phone payments onto secure links, shrink your PCI burden and reconcile per booking instead of per statement.
The Barclaycard ePDQ stack does its job, but the operational picture it produces is rarely shaped for travel. felloh keeps payments, refunds, settlement, trust evidence and supplier disbursements connected to the same booking record from day one.
ePDQ was withdrawn on 31 March 2026, so this is no longer a planning exercise — it is a replacement decision. felloh runs a phased migration with both stacks in parallel, so web and phone payments keep flowing while you cut over brand by brand.
The e-Terminal meant staff hearing and keying card details, with the fraud liability sitting on you. felloh replaces keyed MOTO with secure payment links the customer completes themselves — 3D Secure authentication typically shifts chargeback liability to the issuer, and your team never touches card data.
ePDQ reported at transaction level and finance rebuilt the booking picture from statements. In felloh, every payment, refund and settlement attaches to the booking — finance, customer support and dispute teams read from the same record.
ATOL Trust positions, protected funds and trustee reporting attach to the booking automatically. The evidence pack for audits, trustees and acquirers comes from the record your team already reads.
Most Barclaycard ePDQ concepts map directly. A few — bookings, refund authorisation, scheduled payments — are felloh-specific because travel demands them.
You can map most of Barclaycard ePDQ onto felloh directly. These are the differences travel teams actually feel during cutover — and after.
Instead of staff keying card details into the e-Terminal, you send a payment link tied to the booking. The customer authenticates with 3D Secure, liability typically shifts to the issuer, and PCI scope shrinks.
The booking is a typed record that every payment, refund and settlement attaches to. The link between a transaction and a trip stops living in spreadsheets.
Settlement files unpack to per-booking fees, refunds and chargebacks. Bank transfers match against bookings without manual reference chasing.
The felloh API is built around the booking. The same record carries the customer, the supplier obligation, the payment trail and the trust position — so finance, customer support and dispute teams all read from one place.
See the full Barclaycard ePDQ migration guideThe travel-specific layer comes built in. ATOL Trust, supplier disbursements, scheduled instalments, two-stage refund authorisation and automatic reconciliation — all live against the same booking record.
Every payment, refund and settlement lives against the booking it relates to. Finance, customer support and dispute teams all read from the same record.
ExploreRefunds are initiated by one user and approved by another, with the underlying booking, supplier-payment and policy context surfaced inline.
ExploreProtected funds, ATOL Trust positions and trustee reporting are part of the same operating record — not a separate compliance project.
ExploreSettlement files unpack to per-booking fees, refunds and chargebacks; bank transfers match against bookings without manual reference chasing.
ExplorePay suppliers and beneficiaries directly against the bookings they relate to, with the full audit trail attached.
ExploreDeposit-then-balance flows, instalments and balance reminders run from the booking record with network-tokenised cards that stay current.
ExploreCutover is reversible at every step. Move data and flows brand by brand, with parallel processing while you confirm acceptance and settlement timing match your existing baseline.
Provision sandbox credentials, wire SDKs into a non-production environment and validate authentication, webhook signing and a sample booking-payment flow.
Move customer, booking, beneficiary and card-token records across. felloh imports existing card tokens directly from your current acquirer where scheme token-portability is supported, so customers do not need to re-enter card details for live bookings.
Move payment collection, refund, settlement and reporting flows brand by brand. Run both stacks in parallel so cutover is reversible at every step.
Switch live volume across, monitor acceptance and settlement timing against your existing baseline, then decommission the legacy integration on a schedule that suits the dispute window.
Bring us one Barclaycard ePDQ workflow you want to fix and we'll show how felloh wires payments, settlement, refunds and trust evidence around the booking.
