Accepting AZUL Payments
AZUL is the payment processor for Dominican Republic businesses. If your customers pay in Dominican pesos and your merchant account is with AZUL, this is the gateway you use in Suprata.
AZUL is set up differently from Stripe and Usio, and understanding why saves you a confusing first week. There is no self-service enrollment wizard: AZUL issues your merchant credentials and a security certificate by hand and certifies the integration before it goes live. Support turns AZUL on for you — you don't connect it yourself. Once it's live, though, the day-to-day is yours, and that's what this article covers.
The one thing to understand first: two separate rails
AZUL online and AZUL in person are two different merchant accounts with two different capabilities, and Suprata keeps them separate on purpose.
| Online payment | In-person payment | |
|---|---|---|
| Where | Customer pays their own invoice, or saves a card in the portal | Staff take the card at the counter |
| What actually happens | A real charge goes through AZUL, with 3-D Secure | The card runs on your AZUL card terminal; Suprata only records it |
| Does Suprata move the money? | Yes | No — the terminal did |
| Refunds | Through AZUL, from the invoice | On the terminal, then recorded here |
The single most important consequence: when your staff select a credit card on an invoice, Suprata does not charge the card. It records a sale that already happened on your physical AZUL terminal. Suprata even tells you this on screen when you do it. If you forget, you'll record payments that were never actually taken.
Why in-person is "record only"
AZUL's card-present terminals are standalone hardware on a separate merchant account. They aren't wired into Suprata, and there's no way for Suprata to reach across and run a charge on them. So the honest — and only correct — design is: run the card on the terminal, then tell Suprata it happened, so the invoice balance and your books stay right.
This also means AZUL has no "type the card number in" option for staff. That's deliberate, not a missing feature. A keyed online charge would skip 3-D Secure, and AZUL's online rules require it. Phone and counter card sales go on the terminal.
How customers pay online
This is the fully automated side. A customer opens their invoice link, enters their card, and:
- AZUL runs 3-D Secure — the customer's bank may pop up a confirmation step (a code, an app approval, or a "yes it's me" screen).
- Once the bank confirms, the charge goes through and the invoice flips to Paid.
- A payment row appears on the invoice, tagged as an AZUL online payment.
3-D Secure is the reason online payment is safe to leave hands-off: only the real cardholder can approve the charge, and the liability for a disputed payment shifts to the bank. It's also why this only exists on customer-facing screens — a bank confirmation prompt is no use on a staff computer when the cardholder is on the phone.
Saving cards for next time
Customers can save a card in their portal (Payment Methods → Add a card). AZUL stores it as a secure token — never the actual card number — so you can charge it again for recurring billing or a quick repeat payment without asking for the card again.
- Saving a card does not run 3-D Secure (there's no charge to confirm), so it's instant.
- Charging a saved card later runs without a bank prompt, because there's no customer sitting there to answer one. That's the correct behavior for recurring and autopay.
- Paying a brand-new card in the portal runs the full 3-D Secure flow, so Suprata sends the customer to the secure invoice page to do it.
Recording an in-person (terminal) sale
When a customer pays at the counter:
- Run the card on your AZUL terminal and get the approval.
- In Suprata, open the invoice → take a payment → choose Credit / Debit Card (Terminal).
- Optionally type in the auth code and last 4 digits from the terminal slip. Both are optional, but they make reconciliation far easier later.
- Save. Suprata records the payment and shows a reminder that it did not charge the card — you did, on the terminal.
The example that keeps you honest: a customer pays RD$3,500.00 at the front desk. You run it on the terminal, it approves with auth code 084417. In Suprata you record a terminal payment of RD$3,500.00 with that auth code. The invoice now shows paid, and your terminal batch and your Suprata books will match at end of day.
Refunds — read this before you refund a terminal sale
Refunds follow the rail the payment came in on.
- Online AZUL payment → refund it right from the invoice's payment row, same as any other gateway. The money goes back through AZUL. A very recent charge is voided; an older one is refunded — Suprata picks the right one.
- Terminal (in-person) payment → the refund happens on your AZUL terminal, not in Suprata. When you record a refund here, Suprata warns you: recording it does not move any money, because Suprata never charged the card in the first place. Process the refund on the terminal first, then record it in Suprata so the balance is right.
Getting this backwards is the classic AZUL mistake: recording a terminal refund in Suprata and assuming the customer got their money. They didn't — the terminal has to do it.
What we handle vs. what's on you
Because AZUL is a hand-certified integration, the split of responsibilities is worth stating plainly.
Suprata handles: the integration itself, the 3-D Secure flow, the secure connection to AZUL, storing your credentials safely, and showing the card-network security marks customers expect.
You handle: getting your own AZUL merchant account(s) and certificate, your PCI compliance, a clear business name on statements (so customers recognize the charge and don't dispute it), running the physical terminal, and reversing terminal sales on the terminal.
Common mistakes
- Assuming "Credit / Debit Card (Terminal)" charges the card. It records a terminal sale. Always run the card on the terminal first.
- Recording a terminal refund and thinking the money moved. It doesn't. Refund on the terminal, then record.
- Forgetting the auth code and last 4. Optional, but without them a disputed or mismatched terminal payment is painful to trace back weeks later. Type them in while the slip is in your hand.
- Expecting a "type the card in" option for staff. There isn't one, by design. Counter and phone card sales go on the terminal.
- A statement name customers don't recognize. If the name on the cardholder's statement doesn't look like your business, you'll get disputes. Make sure your AZUL statement name is set — ask support if you're unsure what it shows.
- Trying to switch processors casually. As with every processor in Suprata, you run one at a time, and saved cards don't move between them — the stored token belongs to whichever processor created it.