Accepting Portal Dominicana Payments

Portal Dominicana is one of the card processors available to Dominican Republic businesses in Suprata. If your merchant account is with Portal Dominicana, this article explains what your staff and your customers will actually see — and, more importantly, why online payments now include a step where the customer's bank may ask them to confirm.

Like AZUL, Portal Dominicana is not a self-service sign-up. They issue your credentials by hand and certify your setup before you go live. You enter those credentials on the Portal Dominicana integration page, use its setup check to confirm everything connects, and once the integration is activated it locks — changing it later goes through support, because every saved card and every past payment is tied to that one merchant account.

The two kinds of card payment

That last row is the reason this matters. Read on.

What 3-D Secure is, and why it's on

3-D Secure is the "confirm it's really you" step you've probably seen when shopping online: a code by text message, an approval in a banking app, or nothing visible at all when the bank is already confident.

It does two things for you:

1. It stops stolen cards. Someone with a stolen card number can't answer the bank's question.
2. It moves the liability. When the bank confirms the cardholder and that payment is later disputed as fraud, the loss is generally the bank's, not yours. Without it, a fraud dispute on an online payment comes out of your pocket.

That's why it runs automatically on every online payment for Portal Dominicana businesses — there's nothing to switch on.

What your customer sees

When a customer pays an invoice online — from the emailed link or inside the portal — they enter their card as usual and press Pay. Then one of three things happens:

• Most of the time, nothing extra. The bank checks quietly in the background and the payment goes straight through. The customer just sees it's paid.
• Sometimes, a "Confirm with your bank" window. It shows the bank's own page — usually "enter the code we texted you" or "approve in your app". Once they do, the window closes by itself and the payment completes.
• Occasionally, a refusal. If the bank can't confirm them, or they close the window, the payment is stopped and nothing is charged. They'll see a message saying exactly that, and can try again or use another card.

Two details worth knowing so you can answer the phone confidently:

• If the customer's bank simply doesn't support the check (some cards don't), or the check service is down, the payment still goes through — without the protection, the same as before. We'd rather take the payment than turn a paying customer away.
• The online form needs JavaScript turned on in the browser. Every normal browser has it on; if a customer has deliberately disabled it, the page tells them it needs it, and nothing is charged.

Saved cards

• Saving a card in the portal now also asks the bank to confirm it. No money moves — this is about making sure the person adding the card really owns it, so a stranger can't park a stolen card on a customer's account.
• Paying with a saved card in the portal can also bring up the bank's window. The customer is right there, so the bank is allowed to ask, and a confirmed payment carries the same protection as a new card.
• Recurring billing and autopay never ask. There's no one at a screen to answer, so those charges run on their own exactly as before.

Online bookings

Guests paying a deposit through the booking widget on your website get the same check. If their bank asks them to confirm, it opens right inside the widget and the booking completes when they do. If they don't finish it, nothing is charged and the booking waits in your online-bookings inbox as an unpaid draft — check the deposit before you confirm one. The card they paid with is saved on the reservation for settling the balance at check-in, as it always has been.

Phone and counter payments

Staff can type a card in, or swipe one, on the usual payment screens. There's no bank confirmation step here — the bank would be asking your staff member, not the cardholder — so you carry the risk if one of these is disputed as fraud.

You can't add 3-D Secure to a phone payment, but you can make phone payments safer:

• Keep the billing address accurate. Suprata fills in the account's own billing address on the card form and sends it to the bank, which checks it against the card. Correct it if the cardholder gives you a different one.
• For bigger or unusual amounts from a new customer, send the invoice link instead. The customer pays it themselves, the bank confirms them, and the risk moves off you. A RD$45,000 deposit from someone you've never met is exactly the payment that should go through the link, not over the phone.

Common mistakes

• Taking a large first payment over the phone "to be helpful". It's the one payment type with no fraud protection. Email the invoice and let the customer pay it online.
• Telling a customer the payment went through when they closed the bank window. It didn't — nothing was charged. Ask them to try again and complete the bank's step.
• Assuming a refused online payment is a Suprata problem. If the message says the bank couldn't confirm the payment, the decision came from the customer's bank. The customer should call the number on the back of their card.
• Expecting autopay to prompt the customer. It never does, by design. Only payments a customer makes themselves can be confirmed.
• Changing processors casually. Saved cards belong to the processor that created them. Moving away from Portal Dominicana means every saved card has to be entered again.

Related articles

• Accepting AZUL payments
• Saved payment methods — when to use them
• Handling a customer dispute
• Refunds and partial refunds
• Credits vs. refunds vs. voids