Faster Payments at Plum

Since its inception Plum has used Direct Debit as the mechanism for saving money for its customers. Direct Debit is great for several reasons:

• customers don’t need to authorise every single payment;
• the amount that is transferred with each transaction can vary;
• the money transferred is protected by the Direct Debit Guarantee;
• the price per transaction is low compared to alternative methods, such as credit and debit cards.

Sounds great, right? Well… there are downsides.

The main issue with Direct Debit is speed. From the point Plum requests money to the moment it lands in a customer’s pocket takes two working days. This applies to existing customers only. New customers first need a mandate, which is essentially an agreement to let Plum draw money from their bank as and when. This also takes two working days to establish. By 21st century standards, this seems positively glacial, especially in cases where a customer has explicitly requested a lump deposit manually, without relying on Plum’s algorithm.

Direct debit timings. Customers with existing mandates jump straight to day 2.

But hang on. Don’t bank-to-bank transfers normally take up to two hours? Why can’t Plum’s manual transfers be made this way instead?

Ask us this twelve months ago and the answer would’ve been “the tech isn’t there yet”. The intervening period has seen huge progress in the integration of bank-wire transfers, or Faster Payments, into the Open Banking tech ecosystem.

How it Works

Plum’s new Faster Payment flow.

By their very nature, Faster Payments necessarily require more customer-interaction than Direct Debit. The customer must explicitly authorise each payment. So, manual deposits only.

The first step in the Faster Payments flow involves instructing Plum to create the payment. This involves a call to our deposit API endpoint, which prior to Faster Payments accepted an amount and an identifier for the destination of the deposit (e.g. a pocket or investment fund).

In addition to these, the endpoint now accepts an optional method field, which clients can use to specify the mechanism used to deposit the amount. Currently supported methods are 'direct_debit' and 'faster_payment'. With these inputs, the endpoint dutifully builds the database entities that describe the deposit and calls the relevant partner-API endpoint.

We use GoCardless as our Direct Debit provider, and we’ve recently integrated with our long-standing aggregation partner, TrueLayer, to provide our customers with Faster Payments into their Plum pockets.

To kick things off we ask TrueLayer for a credentials grant, which is essentially an access token that expires after a fixed period of time. This token is then used when creating a payment and querying its status.

TrueLayer require a few things from us before they can set up the payment:

• beneficiary bank details,
• remitter bank details,
• references for the remitter and beneficiary,
• the bank of the customer making the payment,
• a redirect URL to direct the customer to after they’ve finished authorising the payment.

Thankfully we already have all this information. Every pocket has its own bank details, so we simply fetch these when the customer sets up the payment. We also know the customer’s bank details as a result of linking to their account. We’re free to choose the references for the transaction, but we intentionally make the reference unique to enable us to reconcile the deposit in our system against payments that arrive in our accounts. With all this information in hand, we can then instruct TrueLayer to set up the payment.

The response from TrueLayer’s payment API includes an 'auth_uri' field, which we direct the customer to to begin the authorisation flow. From this point the customer experience will vary depending on who they bank with. Some banks, particularly the challenger banks, have provided a better authorisation experience than others.

Once the customer has authorised the payment, TrueLayer sends them back to the redirect URL we provided them with when we first created the payment. Upon arrival, we take the opportunity to synchronise our database with TrueLayer before sending the customer back to the app to complete the flow.

During this journey, the status TrueLayer hold for the payment progresses from `new` through to `executed`. The ‘happy’ flow for these states goes like this:

1. new — the payment has been created and is awaiting customer authorisation;
2. authorised — the payment has been authorised by the customer;
3. submitted — the payment request has been submitted to the customer’s bank;
4. executed — the customer’s bank has processed the payment and sent the required amount to the destination.

Note that these statuses are framed from the perspective of the remitter. That is, the person sending the money. Once the payment is marked as executed we know the money has been sent, but nothing more.

To complete the circle, we rely on webhooks provided by our e-money provider, RailsBank. Whenever the state of a customer’s pocket changes, we receive updates notifying us. When the Faster Payment arrives, we take the transaction reference we gave to TrueLayer earlier and use it to look the transaction up in our database. We then mark the transaction as successful, at which point the customer will see the money in their pocket.

Outlook

It’s still early days here for Faster Payments at Plum. As of writing we currently have a payment success rate of about 66%. Some of these failures are down to a customer’s bank running into technical problems and rejecting the payment, but in a lot of cases the flow to authorise the payment is long or awkward. Our success rate for Santander customers, for example, currently stands at about 43%, and 93% of these failed payments are down to customers abandoning the flow. This is frustratingly out of our control, since the experience here is controlled mainly by the customer’s bank. Hopefully as the technology matures banks will streamline the process, and these metrics will improve.