PISP (Payment Initiation Service Provider)

A payment initiation service provider, or PISP, is a licensed firm that can start a payment from someone's bank account on their behalf. The customer stays in charge throughout: they approve the payment in their own banking app, and the bank moves the money. The PISP does not hold the funds, and it does not see the login details. It asks the bank to begin, once the customer has said yes, and that narrow role is what the licence is built around.

The role did not exist before open banking rules created it, because until then only the bank itself could start a payment from an account. A shop wanting money from a bank account had to send the customer off to make a manual transfer, then hope it arrived with the right reference on it. A PISP closes that gap. It turns a bank transfer into something a checkout can offer directly, with a status that comes back in seconds instead of a wait and a guess.

How A Payment Runs

The shopper picks pay by bank and chooses their bank. The PISP builds the payment instruction from the order. The shopper is then handed to their own banking app to approve it. The bank checks who they are, moves the money, and returns a status. The shop gets that status and can release the order. All of it happens on a home market network, often an instant one such as Faster Payments.

What The PISP Can And Cannot Do

It can build the instruction, ask the bank to start it, and read the status afterwards. It cannot hold the money, take more than the customer approved, or store the bank login. Those limits are the point of the licence, and they also shape the product: because funds move straight between accounts, there is no float and no settlement account sitting in the middle.

The Rules Behind It

Banks have to offer a working route for licensed firms, not merely a route that exists on paper. The technical standards say an access route has to let a firm say who it is and talk over a link nobody else can read. Article 30 of those standards also asks banks to publish the technical detail free of charge, give notice before they change it, and offer a way to test ahead of launch. The UK Open Banking API standards turned that duty into one shared rulebook instead of nine different ones.

PISP Set Beside A Card Payment

A card payment pulls money and a PISP payment pushes it, which flips several things at once. There is no chargeback in the card sense, so a business carries less reversal risk and a shopper carries less protection. Fees have a different shape, and the money tends to arrive faster. The shopper approves in a bank app instead of typing card details, which some find reassuring and others find slow.

Where It Fits Best

High value payments suit it, because card fees bite hardest there. So do account top-ups, where the customer is moving their own money, and bill payments, where the amount is known and the payer is checking a balance anyway. It also reaches people who have a bank account but no usable card, which matters more in some markets than others. Businesses selling to other businesses find it useful too, since a consumer to business flow is not the only shape it supports.

Refunds Need Building

This is the part teams get wrong most often. There is no reverse button on a pushed payment. A refund means sending money back as a separate transfer, and that needs the payer's account details and a process to set it off. That is straightforward to build and easy to forget until the first return request arrives. Any business offering pay by bank should design the refund path before launch, not after it.

Coverage And Performance Vary

Not every bank performs equally well. Some routes are fast and reliable, while others time out or drop the customer part way through, and support for features such as repeat payments differs by market and by rulebook version. So success is worth tracking bank by bank, not as one blended number. A single poor performer can drag the average down and hide a healthy picture elsewhere. Where a bank route is weak, offering a card fallback keeps the sale.

What It Costs To Accept

Pricing is usually a flat fee per payment instead of a percentage, which is why larger baskets favour it. There is no interchange, because no card network is involved. Against that, the business gives up the reversal protection a card brings, and takes on a refund flow it has to build itself. The honest test is not fee against fee. It is the total cost per completed sale, and that has to include the sales lost to a slower approval step.

Picking The Right First Use Case

Pick a use case that suits the shape instead of switching a whole checkout over. Show bank names and logos early, since people finish more often when they see a name they know. Handle the return journey from the banking app with care, because that is where drop-off clusters. Build the refund path before launch. Track success by bank and by market. And keep open banking options alongside cards, not in place of them. Open banking payments covers the product side. This piece on instant bank payments for merchants covers the commercial case.

‍