Frequently asked questions.

Pay by bank lets a customer pay straight from their bank account instead of using a card. They choose their bank, approve the payment in their banking app, and their bank sends the money to yours. It runs on open banking payment initiation, regulated under PSD2 in the EU and the Payment Services Regulations in the UK.

We create the payment, show the customer a checkout to choose their bank, request their consent, execute the payment once they approve, and tell your server the outcome with a signed webhook. Payment initiation runs through Yapily's open banking network.

The United Kingdom for GBP and banks across the EU for EUR. The checkout only lists banks that support the payment you requested. Ask sales about a particular bank or market.

Businesses registered in the UK or the EEA, subject to our onboarding checks and acceptable use policy.

No. They only need online or mobile banking with a supported bank.

Never. Customers approve the payment on their own bank's screen. We receive the outcome, not their credentials.

The checkout shows a QR code. They scan it, approve on their phone, and the page on their computer completes by itself. The desktop button switches off once the phone has started, so the payment can't be made twice.

Your server still gets the webhook, so the order is settled correctly either way. If the customer returns to your page and you've turned on resume, the button picks the payment back up and shows the result. A payment where no bank was chosen is cancelled after about 60 minutes.

Yes. The receipts page lists payments made from that browser. It's stored on the device and isn't linked to an account.

No. The customer's bank pays your registered bank account directly. We orchestrate the approval and never pool or hold funds.

If you request the instant rail and the customer's bank supports it, the payment settles in seconds. Otherwise it goes as a standard domestic payment. The payment record shows which rail was actually used.

Yes, by contacting us. It can't be changed through the API. That's deliberate: even a leaked API key can't send your payments somewhere else.

A per-transaction fee agreed in your merchant agreement. Ask sales for a quote based on your volume.

No. Pay by bank payments are approved by the account holder in their bank and aren't covered by card scheme chargeback rules. Customers can still ask you for a refund under your own policy.

Rotate it straight away. The damage is limited by design: requests have no payee field, so a stolen key can't divert money, and keys can only read your own payments.

The portal uses a read-only dashboard token (dash_…). You can give it to finance or support staff without giving them the power to create payments.

No. The checkout can only be framed on the domains registered for your account, and browsers enforce that.

Every webhook is signed with an HMAC-SHA256 of its body using a secret issued only to you. Verify it before acting on the event. The developer guide has the code.

The typical integration is one endpoint, one button and one webhook handler. Most teams finish it in a day, including testing in the sandbox.

You don't need one. The API is plain HTTPS and JSON, so it works from any language. The pay.js button covers the front end.

Yes. Pass institutionId when you create the payment and redirect the customer to the authorisationUrl in the response. Most merchants let our checkout handle bank choice instead.

Yes. The sandbox runs the full flow, including a stub mode that needs no bank credentials, so you can test your webhook handling end to end. See the sandbox notes.