2,256 candidates for a payments platform that spans 49 countries

Two years embedded in the talent team of a global issuer-processor, through a merger that doubled the company. Every candidate tracked, every rejection reasoned, and a conversion rate we could argue about with data rather than opinion.

2,256Candidates screened
144Approved and put forward
2 yearsEmbedded in their team

TL;DR

  • Who. Paymentology, the world's first global issuer-processor, formed when Tutuka merged with Paymentology in December 2021. Between them they issue and process card payments across 49 countries, including virtual cards for banks and fintechs.
  • What they needed. Engineering hiring capacity while the business was doubling. Backend and software engineers, support engineers, QA and DevOps, hired remotely.
  • Why it was hard. A payments company screens harder than most, because the cost of a weak hire is regulatory as well as commercial. The process ran to six stages including a delivered project, and the drop-off was heavy at every one of them.
  • What we did. We put a recruiter inside their talent team on an RPO model, and we instrumented the whole funnel: every candidate, every stage, every rejection with a reason and an owner.
  • What happened. 2,256 candidates through the funnel, 144 approved and put forward, and around seven or eight hires in the first year, across a two-year engagement.

About Paymentology

Paymentology is an issuer-processor: the infrastructure that sits between a bank or fintech and the card networks, authorising and processing transactions in real time. It powers physical, virtual and tokenised cards for banks, challengers and fintechs, with a particular strength in virtual card issuing.

Its current shape was formed in December 2021, when Tutuka, out of South Africa, merged with Paymentology in the UK to create what the two companies described as the world's first global issuer-processor, spanning 49 countries. We started working with them as Tutuka, before the merger, and the engagement continued through it.

The engineering organisation was distributed and hiring remotely, which is why a recruitment partner who works that way was a fit in the first place.

The brief

Add engineering hiring capacity to an internal talent team during a period of rapid growth and then a merger. Backend and software engineers as the core of it, plus support engineers, QA and DevOps. Remote hiring, run end to end, with our recruiter working as part of their team rather than sending profiles from outside.

The 4 problems we had to solve

Problem #1: "We are merging two companies and still hiring through it."

Tutuka and Paymentology came together to create a business operating across 49 countries. Mergers are usually where hiring pauses: the org chart is provisional, the roles are being redefined and nobody wants to commit headcount until the dust settles. Pausing was not an option, because the growth that justified the merger required the engineers.

What we did

We kept the pipeline running through it. Because our recruiter sat inside their talent team rather than pitching from outside, the searches did not need to be re-explained to a new set of stakeholders, and the work continued across the change of company name.

Problem #2: "Almost everyone gets rejected, and we need to know why."

The drop-off was severe. Of 2,256 candidates who entered the funnel, 144 were approved to go forward. That is roughly one in sixteen. In that situation the important question stops being "how many candidates" and becomes "why is everyone failing, and at which stage".

What we did

We instrumented it. Every candidate was logged with a submitted date, a date for each stage, days between stages, a rejection date, a rejection reason and, critically, who did the rejecting: the candidate or the client. "Lacks experience", "poor English", "took another job", "wrong expectations", "failed project". Once the rejection reasons are counted rather than remembered, the conversation with a hiring manager stops being a matter of opinion.

Problem #3: "Inbound and outbound do not behave the same way."

Applications and sourced candidates are usually treated as one pipeline. They are not. They convert differently, they cost different amounts of recruiter time, and mixing them makes it impossible to know where the effort should go.

What we did

We tracked them separately, every week, for the whole engagement. Inbound produced 614 applications and 61 approved candidates, a 10% approval rate. Outbound produced 1,642 sourced candidates and 83 approved, a 5% rate. Outbound converts at half the rate and still produced more approved candidates in absolute terms, which is exactly the kind of finding that changes where a recruiter spends Tuesday.

Problem #4: "Our process is six stages long and candidates are dropping out of it."

Their process ran: application, tech lead interview, culture chat, project delivery, project review, project presentation. Good candidates were being lost partway through, and "took another job" appears repeatedly in the rejection log.

What we did

We measured the process, not just the candidates. Average time between stages: nine days from application to tech lead interview, seven to the culture chat, six to project delivery, six to project review, then eighteen days to the presentation. Putting those numbers in front of the client turns "we are losing candidates" into a specific conversation about a specific gap. Candidate management filled the space in between, because on a six-stage process most of the recruiter's job is keeping good people warm.

How we actually ran it

  1. A recruiter inside their talent team. RPO, not agency. One of ours embedded for around two years.

  2. A written intake per role. Backend and software engineers, support engineers, QA, DevOps.

  3. Weekly KPI tracking, split by channel. Applications, candidates sourced, interviews conducted, candidates approved and interviews scheduled, inbound and outbound recorded separately, every week.

  4. Every candidate tracked stage by stage. Dates at each step, days between steps, rejection reason and rejecting party.

  5. Candidate management across a long process. Six stages including a delivered project is a long time to hold someone's attention, and that holding is the work.

What Paymentology ended up with

  • Engineering hiring that continued through a merger instead of pausing for it.

  • 2,256 candidates screened so that their engineers only met the 144 worth meeting.

  • Around seven or eight hires in the first year, across backend, support, QA and DevOps.

  • A rejection log with reasons and owners, which is what makes a hiring-manager conversation evidence-based rather than anecdotal.

  • Separate conversion data for inbound and outbound, and therefore a defensible answer to where recruiter time should go.

  • Measured time-in-stage across a six-step process, including the eighteen-day gap nobody had noticed.

Written by

Miguel Marques

Miguel Marques

Remote Crew