Mercado Pago Fraud Prevention: Device Signals Before Checkout

If you sell online in Latin America, there is a good chance a large part of your payments run through Mercado Pago. It handles cards, local payment methods and installments, and it scores transactions on its side. But a lot of the fraud that reaches a payment never looks like a payment problem until the chargeback arrives. It starts earlier, in your store: a new account, a reused coupon, a login that isn’t the owner.

This post covers the patterns that hit merchants accepting Mercado Pago and how to score the session on your own side before you send anyone to pay. To be clear up front: Prynt has no partnership or integration with Mercado Pago. Everything here runs on your pages and your server, and it would look the same with any processor.

What the processor sees, and what it doesn’t

A payment provider sees the transaction: the card or payment method, amount, the buyer data you pass, and whatever device data its own tools collect. Mercado Pago documents device-identification and anti-fraud fields for integrators; follow its guidance, because sending richer data generally helps its scoring.

What no processor sees is your business context:

• That this browser created four accounts in your store this week.
• That the account placing this order was logged in from a different device an hour ago, after a password reset.
• That this device already redeemed the first-purchase discount under another email.
• That the last three orders from this device ended in chargebacks or “not received” claims.

Those are the facts that separate a good customer from a problem, and they live in your database joined with a device identity.

Pattern 1: card testing

Card testers use your checkout to validate stolen card numbers with small purchases or authorizations. The tell is repetition: many attempts, many cards, often from one device or a small cluster of devices, often automated.

On your side, score the checkout session before creating the payment:

• Velocity per device. Count payment attempts and distinct cards per visitorId over the last hour. A real buyer retries once or twice.
• Automation signals. BOT, TLS_AUTOMATION and AUTOMATION_BEHAVIOR on a checkout page are not ambiguous.
• Network. DATACENTER or RESIDENTIAL_PROXY on a checkout, especially with velocity, is a strong combination.

When those fire, stop before the payment call. Card testing also costs you in processor fees and in your standing with the processor, so cutting it off before the API call matters. More detail is in card testing detection at checkout.

Pattern 2: promo and first-purchase abuse

Welcome coupons, free shipping on the first order and cashback promotions are common in LatAm ecommerce and widely farmed. One person, many emails, one phone or laptop.

Link every account to its device at registration, and at checkout check whether this device has already redeemed the offer under another account. accountsOnDevice on the event lists every account you’ve linked to that device; join it against your redemption table. This is not a payment-risk question at all, which is exactly why the processor can’t answer it. See ecommerce fraud prevention for the broader pattern.

Pattern 3: account takeover before purchase

Stored addresses, saved payment methods and loyalty balances make a store account worth stealing. The tell is a device the account has never used, often right after a password reset or email change, followed by a quick order to a new address.

At login and again at checkout, compare the current visitorId with the account’s known devices. A new device plus a changed shipping address plus a high-value cart deserves a step-up such as a one-time code to the original email before the order goes to payment.

The flow: score, then pay

Identify on the checkout page and send the requestId with the order:

<script src="https://api.pryntid.com/cdn/prynt.umd.js"></script>
<script>
  const ready = Prynt.load({ apiKey: 'pk_live_…' })
    .then((a) => a.identify({ tag: { action: 'checkout' }, linkedId: window.customerId }))
    .catch(() => null);

  async function placeOrder(cart) {
    const r = await ready;
    return fetch('/api/orders', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ cart, pryntRequestId: r?.requestId || null }),
    });
  }
</script>

On the server, verify before you create the Mercado Pago payment or preference:

import { PryntServer } from '@prynt/node';
const prynt = new PryntServer({ secretKey: process.env.PRYNT_SECRET_KEY });

app.post('/api/orders', async (req, res) => {
  const ev = req.body.pryntRequestId
    ? await prynt.getEvent(req.body.pryntRequestId).catch(() => null)
    : null;

  const attempts = ev ? await countAttemptsLastHour(ev.visitorId) : 0;
  const reasons = ev?.risk?.reasons || [];

  if (ev?.decision === 'block' || attempts > 5) {
    return res.status(403).json({ error: 'checkout_unavailable' });
  }
  if (ev?.decision === 'challenge' || isNewDeviceForAccount(req.user, ev)) {
    return res.status(409).json({ next: 'verify_identity' });
  }

  const order = await createOrder(req.user, req.body.cart, { visitorId: ev?.visitorId, riskScore: ev?.riskScore, reasons });
  const payment = await createMercadoPagoPayment(order); // your existing integration
  res.json({ payment });
});

Store the visitorId, riskScore and reason codes on the order. When a dispute arrives weeks later, you have evidence of which device placed it and what it looked like at the time, which is useful for chargeback representment and for spotting the same device on the next order.

Don’t punish the buyer you want

LatAm traffic has its own quirks that can trip naive rules. Mobile carriers put many users behind shared IPs. Some buyers use VPNs for routine privacy. Cross-border shoppers have legitimate country mismatches. Avoid blocking on any single network signal. Use the decision and combine signals, and prefer verification over refusal for anything that isn’t clearly automated.

Also decide what happens when there’s no requestId, such as when a script is blocked or the browser sends Global Privacy Control. For low-value orders, let it proceed and rely on the processor. For high-value orders, require login or verification.

Where to start

Begin by logging, not blocking: attach the visitorId, decision and reason codes to every order for two weeks. Then look at your chargebacks and refunds from that period. If they cluster on a few devices or on specific reason codes, you know exactly which rule to turn on. The payment fraud detection page and the ecommerce solution page describe the signals in more depth, and stolen card detection at checkout covers the card-not-present side.

Your processor protects the payment. Protecting the account, the coupon and the checkout session is still your job, and it’s the part only you have the data for.