When someone asks us which payment gateway is best, the honest answer is: almost any of them. They all charge, they all settle, they all have a dashboard.
What ends up costing you later isn't that decision. It's these other ones, which are usually made without much thought and are pretty hard to reverse.
A payment isn't an event, it's a state machine
The most common mistake is treating a payment as something that happens once: the customer pays, done. In practice, a payment moves through several states — pending, approved, rejected, under review, refunded, charged back — and can move between them days later.
If the system only understands "paid / not paid," every intermediate state turns into a phone call. The bank transfer that settles 48 hours later, the cash payment the customer makes on Friday, the partial refund: all of that exists and will happen.
Modeling the states from the start adds almost no extra work. Adding them later, once there are thousands of orders with a boolean, is a migration.
Never trust the browser to confirm a payment
This is the one we've seen implemented wrong the most, and it's a security problem, not a tidiness one.
The intuitive flow is: the customer pays, the gateway redirects them back to your site with a "done," and your system marks the order as paid. The problem is that redirect goes through the customer's browser, and anyone can build it by hand. You're letting the buyer be the one who tells you whether they paid.
Confirmation has to come from the webhook: a server-to-server call from the gateway, verified with its signature. The browser redirect is there to show the customer something nice, nothing more.
And the webhook comes with its own fine print: it can arrive before the redirect, it can arrive duplicated, and it can arrive twice with different statuses. That's why it has to be idempotent — processing the same notification twice can't charge twice — and you need to store the raw event, which is the only thing that saves you when you have to audit what happened.
Amounts don't go in a float
It sounds like a purist's detail until a $10,000 order shows up that added up to $9,999.99.
Floating-point decimal numbers don't represent values like 0.1 exactly. The differences are tiny per operation and they accumulate. Store them as integers — cents — or as an exact decimal. Never as a float.
It's one line of code on day one and an accounting headache a year later.
Reconciliation is part of the project
Every site that charges money needs to, sooner or later, answer: does what my system says match what the gateway says and what actually landed in the bank?
If that question can't answer itself, someone is going to answer it by hand with a spreadsheet every month. And they're going to find differences, because there always are: fees, withholdings, installments, refunds.
You don't need to build an accounting system. It's enough to store the gateway's transaction ID alongside each order and be able to list discrepancies. It's little work if it's thought through from the start.
What's specific to Argentina
Argentina has particularities that don't show up in the English-language documentation:
- Installments. The financing cost can fall on the merchant or the customer, and that changes the price shown. It's a business decision that affects the code.
- Withholdings and taxes. What settles isn't what was charged. If the system assumes it is, reconciliation will never close.
- Multiple methods coexisting. Card, transfer, wallet, and sometimes cash. Each with its own settlement time.
That last point is the one that impacts the operation the most: if the system doesn't know a transfer takes time, someone is going to have to check online banking by hand to release orders.
The summary
Choose the gateway based on support and cost, which is where they actually differ. But design the payment as a state machine, trust only the webhook, store amounts as integers, and have reconciliation solved from day one.
That's what makes the difference between a checkout that works and one that works and lets you sleep at night.
In our e-commerce case studies we show projects where this is solved. If you're about to build a checkout, write to us.
