Where Rebill Came From

Back in 2018, when I started building the first version of what would later become Rebill, I wasn’t thinking about infrastructure. I was just solving a specific problem for an insurance company in Argentina. They needed a way to collect recurring and on-demand payments from their customers through Mercado Pago. It sounded simple, until we learned that Mercado Pago didn’t have a proper API for billing or subscriptions.

This was one of the largest and oldest insurance companies in the country, with more than a hundred years in the market, so they had enough influence to get five representatives from Mercado Pago to visit their offices. I was hired to build the integration and help them accelerate other tech projects that were stuck in the backlog.

The meeting was surreal. The Mercado Pago team explained that subscriptions were a deprioritized internal project, so the only possible approach was to build a recurring system on top of their card tokenization API. In other words, I would have to create the entire subscription logic myself—billing engine, retry logic, notifications, dashboard, webhooks, and checkout—on top of a single endpoint that was still in private beta and documented in a PDF.

That tokenization flow worked like this: we sent the card’s PAN and other sensitive data to their API, they returned a token, and we could later use that token to charge the customer on demand. Which basically meant I was about to reinvent a miniature Stripe from scratch.

To make it work, I had to build a recurring system that could retry failed payments automatically, create customer notifications and a landing page for manual payments, integrate everything with the insurance company’s internal Oracle database, and synchronize it through AWS using RDS and Lambda with their on-premise servers, which were physically located inside their Buenos Aires headquarters. I also had to develop a secure tokenization service to handle card data, build webhooks for event tracking, and design a dashboard to manage customers and payments.

And on top of that, the company wanted to automate payouts to brokers using referral codes, essentially split payments. Up to now there is no solution like Stripe Connect for LATAM (spoiler alert: we are on it).

Not long ago, I learned that a friend’s company called Mango Payments had been acquired by Mercado Pago around 2015, and one of their engineers was actually the author of that original PDF. Before that, there wasn’t even a tokenization endpoint available at all.

It’s crazy to think about it now, because in 2018 the rest of the world already had these problems solved. In LATAM, this infrastructure didn’t even exist. Anyone who has ever integrated a payment gateway that isn’t Stripe probably knows the same pain: broken endpoints, random error codes, response times over twenty seconds, and documentation that barely helps. That’s not the exception, that’s the rule.

Years later I would understand why. Most acquirers still run on legacy systems, and reconciliation is still handled manually through TXT or Excel files. I wish I could say that has changed in the last seven years, but it hasn’t.

That early project quickly spiraled in complexity. I had to design a reliable system while learning how to securely tokenize cards. Today, most PSPs buy a tokenization license that costs around sixty thousand dollars a year, and pay another twenty to fifty thousand annually to maintain PCI Level 1 compliance. Back then, I didn’t have that kind of budget, so I read every compliance guide I could find, line by line, and built my own open-source tokenization service from scratch, and certified as PCI DSS SAQ-D Service Provider myself (at a $2k per year cost)

That project became Bluebox.sh, a framework that still powers Rebill internally today and helps several PSPs reduce both costs and latency in card tokenization.

What started as a side project for one insurance company became the seed of something much larger: the foundation of what Rebill would eventually become.