Never Make a Status Request Again: How to Communicate with PSPs

PSPs are satisfied when you receive the data you need, even if you get it multiple times

Too many engineers integrate with their payment providers only via API request/response communication.

When they do that, they leave no room for scenarios on which the other end doesn’t make up their mind immediately. For these cases, the solution almost always ends up being a cron job of sorts, one that requests an update to the end provider. This makes confirming that a payment went through unnecessary complex, slower, and more prone to errors.

The trick? Design your payment systems to be asynchronous first.

Every interaction with an external provider that is mediated by computers can be placed in one of three buckets:

• Direct communication: The immediate response contains all the necessary information that you may need to consider the interaction finished.

• Pull-based communication: The immediate response lets you know that the outcome hasn’t been determined. You now have to build a cron job that will repeatedly request the status of the request to the end provider. You don’t have any clue as to when the status will change.

• Push-based communication: You requested a task to be done, and as part of that request, you included a piece of information, called callback_url for example, on which the external provider is going to make a particular request, with a particular payload, that will data regarding the outcome of the task. When that particular request is going to take place is not known in advance.

Notice that the first type of interaction is synchronous, whereas the other two are asynchronous. Notice, too, that the last two are independent to each other: if direct communication is pending, you’re expected to either reach out to the provider, or wait for them to reach out when the status of such request shifts to complete or failed.

Here’s the thing: while Direct and Push-based preserve the ability to receive an immediate response from the provider the moment the interaction is complete, most providers aren’t built to make real-time interaction with their clients a seamless experience.

There are perfectly valid reasons for this, and a handy solution to address this problem.

By the way, this is The Payments Engineer Playbook. If you haven’t noticed, most advice to engineers online is generic: what is the best programming language, the best OS, the best way to pass LeetCode interviews, and a long and inconsequential etcetera.

But there are few publications that address the topic of software engineering narrowed down in the context of a particular domain.

The Payments Engineer Playbook is, in that sense, one of a kind: the only publication meant to help you become more effective and more successful at building software that moves money around.

This week, we’re looking closely at the problems payment engineers like you and me encounter when we communicate with third party providers. And, since regulation pretty much forces us to deal with software systems built by other people, we have no way out.

Payments engineers have to be masters at third party communication. And this week, we’re going to make progress in that direction.

Let’s dive in.