Bre-B vs cards for ecommerce conversion in LATAM

Why this matters

Bre-B is Banrep’s instant-payment standard, live across the Colombian banking system. It does what Pix did for Brazil and SPEI did at scale for Mexico: it turns bank-to-bank transfer into a real-time, 24/7, low-cost rail that any merchant can accept. For the first time, the Colombian operator has a serious alternative to the card rails for ecommerce.

The temptation, especially in the first 12-18 months of a new rail, is to over-rotate. Some teams shift their entire checkout default to Bre-B and treat cards as the fallback. That works in some categories. In others it costs conversion. The right framing is not Bre-B versus cards, it is a routing decision, made per transaction, against the realistic alternatives: Bre-B, PSE, Nequi, Daviplata, cards.

Operators who get this right see meaningful conversion uplift and meaningful unit-economics improvement. Operators who get it wrong end up with a checkout that confuses customers and a finance team reconciling three new rails badly.

What goes wrong

Most Bre-B adoption mistakes come from treating it as a replacement decision rather than a routing decision:

• Defaulting all traffic to Bre-B. It is a great rail, but customers without a Bre-B-enrolled bank account hit friction. Card-first customers and tourists hit friction. A blanket default ignores that the Colombian customer base is not uniform.
• Treating Bre-B and PSE as interchangeable. They are not. PSE is older, runs through bank online banking flows, and has business-hours limitations on some banks. Bre-B is instant and 24/7. Customers experience them differently, and conversion differs.
• Ignoring Nequi and Daviplata as separate options. For low-ticket and unbanked-adjacent customers, the wallet rails still win on conversion. Bre-B is not a substitute for them in those segments.
• Stopping at “we accept Bre-B.” Acceptance is not optimisation. The conversion gain comes from surfacing the right method to the right customer, in the right position in the checkout, with the right cost framing.
• Underestimating refund operations. Bre-B refunds are operationally different from card refunds. Teams that didn’t plan for this discover it the first time a customer requests a return.
• Pricing the routing as if methods were free. Cards carry interchange. Bre-B carries a different cost shape. The right routing decision is a function of both approval probability and unit economics, not just approval.

Operating model

Conversion optimisation across the Colombian method mix is a single decision repeated at every checkout: which method to show first, which to show as alternatives, and which to suppress entirely.

The team that owns this is usually commerce, not engineering. Engineering owns the rails. Commerce owns the routing.

Recommended approach

A working operating model for Bre-B-and-cards routing:

Surface methods, do not bury them. Bre-B as a tab next to cards, with a clear “instant transfer” framing, beats Bre-B as an option three clicks deep. Customers will use what they can see.

Lead with the method most likely to approve, not the cheapest. A 4% conversion gain on cards is worth more than a 30 bps interchange saving on Bre-B for almost every operator. Cost optimisation is a second-pass discipline.

Use Bre-B as the recovery rail. If a card declines, Bre-B is an excellent alternative-method retry. It bypasses the issuer-decline reason entirely and the customer is already in checkout, motivated to complete.

Keep PSE in the mix for the long tail. Some bank-customer combinations still prefer the PSE flow. Removing PSE because Bre-B exists costs a measurable slice of conversion in the first year of migration.

Plan refunds and reversals from day one. Bre-B refunds need their own operational runbook. Teams that don’t set this up before launch end up with a backlog and customer-support exposure.

Watch cohort behaviour over months, not days. Bre-B adoption among Colombian customers is still climbing. A routing decision that was correct in month one may be wrong in month six. Recheck quarterly.

Example architecture

A reference architecture for a serious Bre-B + cards routing setup:

Checkout
    ↓
Method selector
    → customer segment (returning / new / international)
    → ticket size segment (low / mid / high)
    → category segment (one-off / subscription / marketplace)
    ↓
Surfaced method order: [Bre-B, cards, PSE, Nequi/Daviplata]
    (re-ordered per segment)
    ↓
Authorisation
    → approved → ledger entry
    → declined → alternative-method offer (Bre-B if card failed; card if Bre-B failed)
    ↓
Unified ledger across rails
    ↓
Settlement + refund operations (per-rail runbooks)

The two pieces that drive most of the gain: the method selector segmentation (so the right method is shown first, not just listed) and the alternative-method recovery offer (so a failed card doesn’t end the session).

Metrics to watch

Checkout conversion uplift is the headline. Bre-B share is the leading indicator that the surfacing logic is working. Card-fallback recovery via Bre-B is the recovery story, the merchants who treat Bre-B as the retry rail after card decline see the biggest combined-funnel improvement.

Refund cycle is the operational hygiene metric. If Bre-B refunds are taking longer than 24 hours, the rail is being run as a side project rather than as a primary method, and customer support will reflect that.

What to read next