Australian online payments behemoth BPAY has taken another major stride forward in its push to modernise Australia’s payments landscape, opening up a new developer sandpit and releasing four APIs into the market to spur the clean-up of bank legacy systems.
It's a bold strategic move for the low-cost, high-value money pump, which now pushes approximately $450 billion a year in volume, or $1.8 billion a bank day, with the average transaction size sitting at $900.
Whichever way you look at it, it's a volume business that puts the likes of Square (which doesn't disclose dollar volumes) in the shade. More so when you consider Square's latest clip per transaction is 1.6 percent.
BPAY's wholesale processing rate is 31.35 cents per transaction, exclusive of what acquiring banks charge merchants on top.
On Thursday BPAY made public new functionality which lets customers build their own payments batches, retrieve biller details, validate BPAY payments before processing alongside a new customer reference number generator.
The big drop of APIs comes after a year of road testing pilots in BPAY’s customer base, a move that came in response to user demand to securely open up its codebase so that devs can take a stab at creating new and better services.
Assuming uptake is strong – and BPAY is a long game player – the new functionality is set to take a bite out of the credit card and direct debit segments of the payment industry that are ripe for disruption, especially on the domestic payments front.
The sandpit isn’t open slather in terms of access – like the New Payments Platform, it’s a vetted access system to maintain community hygiene and keep miscreants at bay.
And there’s also no getting away from the fact the new API’s are deep, core bank and enterprise tech and as such unlikely to stimulate much publicity from venture capital fueled fintech cheer squads.
Sometimes, quite big shifts happen quietly, especially in mainframe territory. We’ll get to what the APIs do in a moment because it’s easy to miss what they’re about without a little context.
Where BPAY’s customers – that’s banks, big billers like telcos, utilities, real estate agents, appliance retailers (or anyone else that usually takes payments above $200 in value) – will notice a big difference from the APIs is on their own back ends, especially billing and financials systems.
The core offer of the four APIs is essentially streamlined and enhanced connectivity as well as boosted data interchange capability and integrity.
BPAY's general manager of product, scheme and business development, Keith Brown, told iTnews the process started around two years ago with a design thinking push to target user pain points.
Big users wanted access to APIs, neobanks even more so, Brown said.
A year ago it went to beta and now it's live.
Life’s a batch
Back in 2018 BPAY started targeting SMB accounting platforms with a service dubbed “BatchMaker” that plugged into Intuit’s Quickbooks product and let businesses round up different outgoing payments and fire them off all at once.
It also captured the invoice data, validated the payment information and – and this is the killer – automatically figured out the data format each recipient bank need to accept the payment.
That functionality has now been released to the mainstream developer community as an API called (wait for it) “Generate BPAY Batch File” that both validates a set of supplied payments but also creates a batch file in the format of a specified bank.
Batch isn't going away anytime soon.
Constant, real-time payments are great for smaller payment values – indeed BPAY is a core provider of New Payments Platform overlay services like Osko – but when you hit serious scale it makes more sense to run freight trains than trucks or mini-vans.
What people often don’t realise is that like Australia’s rail gauges, each bank likes their incoming data bowled-up differently, creating a massive headache and on-costs for businesses in the process. So there is serious money to be saved.
At the moment CBA, NAB, Westpac, Macquarie and Bankwest formats are available with more to come soon. And no prizes for guessing which of the big four is missed the curtain raiser.
If, like the languid rollout of Standard Business Reporting, your multinational financials vendor isn’t quite sure when they can offer the batch API solution, it could be worth giving them a sharp poke.
The need to know
If there is one line accounts receivable staff in B2B hate hearing it’s “I don’t know why that payment didn’t go through”, especially when issues later resurface as batch errors. Sometimes it’s a manual error, sometimes a format shift that borks data, but it’s painful, expensive and looks bad.
Live transaction runs are also not a great test environment to figure out what payments will hit their mark, or won't. That said, the reality is that businesses making payments often don’t know what money has missed its mark until the list of rejects returns.
The next API off the BPAY block – “Validate BPAY Payment” – lets enterprise customers do a dry run to check for errors before initiating a payments run to weed out the duds before firing a live batch.
That’s especially useful when customer reference numbers (CRNs) are a bit sloppy for whatever reason, whether it’s formatting or good old fashioned user error.
It also irons out the kink in that when people pay their bills, the quality of the data they submit can be pre-groomed before it’s shunted over to their institution to collect, and it happens in real time.
It’s no secret that payments run according to a set of validation rules and checks, most of which require an identifier in the form of a customer reference numbers (CRNs) that are allocated to an invoice to identify both the customer and the account to be paid.
The functionality to generate BPAY CRNs and iCRNs (intelligent CRNs that denote conditions like expiry dates) has also now been ported to an API available to service providers that also allows QR codes to be created online, on email or on paper.
Unsurprisingly (and you know the devs are in charge of the naming and not the marketers) it’s called “Generate BPAY CRN”.
There's also a QR code option, a ‘nice to have’ especially useful for enterprises pushing features like discounts for early payments or time limited offers.
While some of the bigger banks might yawn a bit, greenfields neobanks will likely relish the functionality when it comes to snaring business customers who want full integration with cloud accounting tools out of the box.
And BPAY is making no secret it wants neos as customers as much as its existing base.
Like CRNs, it’s also good to be able to grab biller details in real time and check if they are valid. For banks and service providers alike, there’s a substantial amount of legwork to be avoided if things are validated as correct the first time around, and that includes biller info.
Rounding off BPAY’s API beauty pageant is “Retrieve BPAY Biller Details” which, like its cohorts, leaves little to the imagination. Call us unkind, but we reckon the payments industry as a whole has a bit of a problem embracing ambiguity.
But BPAY does like shunting data and there’s plenty to be had in automating biller detail retrieval.
The data menu includes: Biller Short Name, Biller Long Name, Industry (ANZSIC) Code, Variable Customer Reference Number Indicator, Valid Length(s) of Customer Reference Number and Accepted Payment Methods for a supplied Biller Code.
Like we said, this stuff is down in the engine room of the payments giant but it will start to make its way into operations and financials software fairly soon, especially incumbents like SAP and Oracle are increasingly challenged.
Which isn’t a bad thing at all.