Merchant API

Feedback & Ideas
1

As a developer, I currently have to use third-party APIs to take card payments via a card processor, incurring merchant and processing fees.

What I’d LIKE to be able to do is encourage my customers to get a Monzo card and link it to their account. In so doing they’d be authorizing me to take payments as required, debiting their Monzo account and crediting mine, which I’d do by issuing payment requests via a Merchant API. I’m hoping that since the transactions would all be Monzo-Monzo, that transaction fees would be considerably less than Visa/MC (or even free given that transfers between friends are).

Off the top of my head, I’d suggest the provision of methods along the lines of:

LinkCard(merchantId, cardNumber, cardholderName, expiryDate, CVV)
Allows a Monzo cardholder to authorise a merchant to take payments directly from their card. Returns a token to identify the card for other API calls, so that the merchant does not need to store card details, thus avoiding much of the pain of PCI compliance.

UnlinkCard(merchantId, cardToken)
Allows a Monzo cardholder to revoke a merchant’s authorisation to take payments

Pay(merchantId, cardToken, isoCurrency, amount, narrative)
Request immediate payment

PreAuth(merchantId, cardToken, isoCurrency, amount, narrative, duration)
Ring-fence an amount on the cardholder’s account for future payment. This amount is reserved for the specified duration (max 1 week maybe?) and cannot be spent by the cardholder. Returns a token if successful, or an error if sufficient funds are not available

CompleteAuth(merchantId, cardToken, authToken, amount)
Completes a PreAuth payment. The amount requested for payment may be up to the amount requested during the pre-auth. An amount of 0.00 effectively cancels the pre-auth. There is potential for an account to have insufficient funds if the transaction currency differs from the account currency owing to rate movements - maybe the FX rate at the point of pre-auth should be used, rather than at the point of completion.

The advantages of such an API are:

  • I can pass on some/all of the transaction cost savings to my customers, this making the service cheaper for them
  • In so doing, I can encourage more people to take-up / use Monzo (a worthy quest, if ever there was one!)
1 Like
2

I’m not sure what the point of the Link/UnlinkCard methods are… Monzo’s API access would completely skip the card layer and go straight to the account.

I also imagine that as well as an API link they’d look at doing a Paypal style integration, so you’d just be able to redirect to a Monzo URL saying you want £x for certain services, potentially on a recurring basis, and then Monzo can handle the authentication, etc. and just return to you when it’s been completed.

1 Like
3

Either take a deposit, pre-auth for a £1 or use a credit card. Imagine if every pay-at-pump ring fenced £99 for upto several days.

Also, an API that includes refunds would be nice; they’re way to slow generally.

4

Unfortunately, Monzo has basically no plans to offer services to businesses, and I doubt they’d want to become a card processor pretty much ever. They’d have to build far too many processes for that, and likely keep it separate from their banking offering anyways.

Asking customers to link their Monzo account to yours so you can debit them also sounds awfully like a direct debit :joy:; you know you can use GoCardless for that, and the fees are much, much lower, right? :smile:

But on a serious note, that sounds like some form of terms of service violation down the line.

2 Likes
5

The point of the Link method is for a cardholder to authorise the merchant to debit their card on an on-demand basis, without the merchant needing to store the card details themselves (or use a PCI-compliant third party). Unlink is just so that the merchant can tidy up their repository of “stored cards”

6

One would hope, as with any other pre-auth, that the merchant would be quick to either complete or cancel the transaction once it had completed (eg: petrol delivered)

7

You’re right in that this would be very much like a direct debit. Shame that Monzo aren’t considering businesses accounts - I hadn’t seen that post.

8

Why would they want to use card though? Card is an arbitrary legacy layer in front of a bank account. You’d just authorise the payment from the account and cut Mastercard out of the loop entirely.

9

@Tommy - agreed. Cutting MC/Visa out is entirely the point, but the API would need to provide a means to ensure that the cardholder is authorising FUTURE payments to be taken from their card (like a direct debit, or storing your credit card details in Amazon). If the cardholder enters their card details into the merchant’s website/mobile app, which the merchant then forwards to Monzo in the form of a Link() request, Monzo can verify the card details before providing the merchant with a token that can be used to request future payments directly via the API, rather than via a Payment Service Provider and the Visa/MC network.

10

A token is an outdated way of doing it. The user would simply authorise you to take current/future/recurring payments against their user and you’d be able to request payment from the API when you wanted it and it’d say yay or nay based on what the user has authorised.

11

I respectfully disagree. This means that the user would have to leave the site/app that they’re setting up their profile in, go to the Monzo app, setup the payment instruction, return to the original site/app, which would then have to check that the auth is in place. It’s fragmented and not particularly user friendly.

12

No they wouldn’t, it’d be done by API and/or browser redirect like 3D Secure or PayPal’s cart