How to charge subscriptions with MercadoPago in a SaaS: what I learned building LeadsLocales

To charge subscriptions with MercadoPago in a SaaS you use its subscriptions API, known as preapproval: the user authorizes a recurring charge on their card once, MercadoPago bills it every period and notifies your backend via webhook. The most important rule is that your app activates the plan when it confirms the status with MercadoPago, not when the user comes back from checkout.

That is how billing works in LeadsLocales, my lead-generation SaaS. Here is the flow, the technical safeguards and the business decisions around it.

Why MercadoPago for an Argentine SaaS?

Because your users already have it. A freelancer or agency in Argentina has most likely paid for something with MercadoPago, has their card saved and trusts the checkout. You also charge in pesos, so users do not have to pay in dollars with an international card, which can be a real barrier in Argentina.

Like any payment provider, MercadoPago takes a fee on each payment. Check the current terms on its site before setting your prices, since they change over time and depend on the payout timing you choose.

What is preapproval and how does it work?

A preapproval is a subscription: an agreement in which the user authorizes your account to charge them an amount every period. MercadoPago lets you create them tied to a plan (you define the plan once and each user subscribes to it) or without a plan (you create the subscription with the amount and frequency directly).

Each subscription has a status. The ones you will see most are pending (created, not yet authorized), authorized (active, charged every period), paused and cancelled. Your app needs to mirror that status: it is the source of truth on whether the user is paying. Exact endpoint, field and event names can change, so always keep MercadoPago’s official docs open.

What does the full flow look like, step by step?

• The user picks a plan on your pricing page.
• Your backend creates the subscription in MercadoPago, including an external reference with the user id so you know whose it is later.
• You redirect the user to MercadoPago checkout using the link the API returns.
• The user authorizes the charge with their card or account.
• MercadoPago notifies your webhook that the subscription changed.
• Your backend fetches the subscription by id, confirms the status and activates the user’s plan.
• Every period, MercadoPago attempts the charge and notifies you again. If it fails or the user cancels, your app reflects it.

Why does the webhook activate the plan, and not the redirect?

Because the page users return to after checkout (the return URL) is just that: a page. Anyone can open it by copying the address, users can close the tab before it loads, or the payment can stay pending. If you activate the plan there, sooner or later you will have users on a paid plan who never paid, or users who paid and do not have the plan.

The webhook, on the other hand, is triggered by MercadoPago when something changes. In LeadsLocales, the webhook activates the plan automatically: users come back to the platform and their plan is already active, without anyone doing anything by hand. The return page just shows a "confirming your payment" message.

What safeguards does the webhook need?

• Do not trust the notification body. Treat it as a heads-up and fetch the subscription from the API with your credentials to read the real status.
• Validate the signature. MercadoPago signs its notifications with a secret key you set up in your account: verify it to reject fake calls.
• Respond fast. Return 200 right away and process afterwards. If your endpoint is slow or fails, MercadoPago retries.
• Make it idempotent. The same notification can arrive more than once: processing it twice must not activate two plans or add extra credits.
• Keep a log. Every notification received and every plan change, with timestamps. When a user says "I paid and it did not activate", it is the first thing you will check.
• Test with test users. MercadoPago provides test credentials and test users to simulate the whole flow without real charges.

What does your app do in each subscription status?

Status names follow MercadoPago’s subscriptions API; double-check them in the official docs when you implement.

What stack did I use?

React on the frontend, Node.js with Express on the backend and SQLite as the database. I explain why I chose SQLite in production in the LeadsLocales story. If you are comparing managed backends for your product, Supabase vs Firebase may help.

Frequently asked questions