Request to Pay (R2P)

API-Driven, Merchant-Owned Payment Experiences

Request to Pay (R2P) at Cobre is an API-only collection capability that allows businesses to request payments while fully owning the user experience. Unlike Cobre Checkout, which provides a hosted payment flow, R2P enables merchants (or anyone interested in collecting) to design and control how customers select the payment rail and complete the payment, while Cobre orchestrates the underlying bank-native payment request.

R2P is ideal for companies that want maximum flexibility and brand control over their payment journeys.

1. What Cobre Enables with Request to Pay

With Request to Pay, Cobre allows businesses to:

Initiate bank-native payment requests via API

Use the same local payment rails as Checkout

Design and control their own payment UX

Let users select the payment method and bank

Collect funds directly into Cobre Balances

Track requests and outcomes through transactions and reports

R2P transforms Cobre into a payments orchestration layer, rather than a hosted checkout.

2. Payment Rails Available in Request to Pay

Request to Pay supports the same collection rails as Checkout, ensuring consistency across products.

2.1 Bre-B Dynamic Key

One-time-use Bre-B key

Time-bound and amount-specific

Shared directly with the payer

Immediate settlement upon authorization

Example:
@CBRNEM3SA49250014

2.2 Bre-B Dynamic QR (EMVCo)

One-time QR represented as an EMVCo string

Clients can generate a QR image scannable from banking apps

Ideal for in-person or visual payment experiences

Example:

00020101021126320014CO.COM.CRB.LLA0410@CBRNEM3SA49250014CO.COM.CRB.RED0103CRB5
20400005303170540105802CO5918Pexto Colombia
SAS6006BOGOTA610611011185260014CO.COM.CRB.INC01040.0090560016CO.COM.CRB.TRXID01
32958b636a7d3e404585c0eda76d7689db91860014CO.COM.CRB.SEC0164a26ed16db9812eb18c4
adbae362b1c63c4f4f024e1ecf2f740fece847a0a7b0c80270016CO.COM.CRB.CANAL0103POS812
50015CO.COM.CRB.CIVA01020382260014CO.COM.CRB.IVA01040.0083270015CO.COM.CRB.BASE
01040.0084250015CO.COM.CRB.CINC0102036304FDA5

2.3 PSE

Allows the merchant to control the bank selection experience

Cobre returns a PSE payment link after the request is created

The user is redirected to their selected bank to authorize the payment

Funds are credited to the merchant’s Cobre Balance after completion

Example

Cobre R2P link redirects to PSE directly

PSE load the seleccted bank experience and the payer access it to authorize the payment

2.4 Bancolombia Button

Generates a payment link for Bancolombia users

Redirects customers to Bancolombia’s authorization flow

Familiar, bank-native experience

Example

Cobre R2P link redirects to Bancolombia directly and the payer access to authorize the payment.

2.4 Nequi Button

Generates a Push Notification and a Payment request for Nequi users

Wallet-native authorization

Optimized for mobile-first users

Example

These rails allow merchants to offer multiple payment options within a single custom flow.

3. Webhook Notifications for Request to Pay

Request to Pay at Cobre supports webhook notifications that allow businesses to receive real-time updates about the status of their payment requests. This enables merchants to react immediately to payment events without polling or manual checks.

What Webhooks Enable

With webhooks, merchants can:

Receive notifications when a payment is completed successfully

Be informed of failed, expired, or canceled requests

Update order or invoice statuses automatically

Trigger downstream processes such as:

Order fulfillment

Service activation

Receipt generation

Internal reconciliation

Webhooks turn payment events into actionable signals for merchant systems.

Event-Driven Payment Updates

Each Request to Pay has a lifecycle, and webhook events reflect meaningful changes in that lifecycle, such as:

Payment status

Processing = awaiting user payment

Completed = payment confirmed

Rejected = payment link expired or abandoned

Failed = technical issue

This ensures merchants always have near real-time visibility into payment outcomes.

How Webhooks Fit into the R2P Flow

Conceptually:

The merchant creates a Request to Pay via API

The customer completes the payment through the selected rail

Cobre processes and settles the payment

A webhook event is sent to the merchant’s configured endpoint

The merchant’s system consumes the event and takes action

This model supports asynchronous, scalable payment processing.

4. Owning the Payment Experience

A key differentiator of R2P is full UX ownership.

With R2P, merchants can:

Build their own payment selection screen

Let users choose:

The payment rail

The bank or wallet (when applicable)

Decide how and when to present:

Links (PSE, Nequi, Bancolombia)

Bre-B keys

Bre-B EMVCo strings as a QR image

Cobre provides the payment primitives; merchants design the journey.

5. How R2P Works Conceptually

From a high-level perspective:

The business/merchant creates a payment request via API

Cobre generates the required payment artifact:

Link (PSE, Nequi, Bancolombia), or

Dynamic Bre-B key / QR string

The business/merchant presents this artifact to the user

The user authorizes the payment through their bank or wallet

Funds are credited to the merchant’s Cobre Balance

Transactions and statuses are notified via webhook and available for tracking and reconciliation

The flow is bank-native, secure, and fully traceable.

6. PSE and Bank Selection (Where Applicable)

For rails that involve bank selection (e.g., PSE):

The business/merchant controls how the user selects their bank

Cobre returns the payment link

The user is redirected to their bank to authorize

This enables custom UX patterns, such as:

Embedded bank selectors

Pre-selected banks

Country-specific payment logic

7. Transactions, Reporting & Reconciliation

Every successful R2P payment generates Transactions in Cobre that:

Credit the business/merchant’s Cobre Balance

Reflect the selected rail

Appear in transaction lists and balance statements

Support reconciliation and accounting workflows

Failed, expired, or canceled requests are also tracked for full lifecycle visibility.

8. Typical Use Cases for Request to Pay

R2P is especially well suited for:

Custom e-commerce checkouts

Marketplaces with tailored payment flows

Embedded finance products

In-app payments

Omnichannel experiences (web, mobile, in-store)

It is ideal when Checkout is too restrictive and a bespoke experience is required.

9. When to Choose R2P vs Checkout

Choose Checkout when:

You want the fastest integration

A hosted flow is sufficient

UX customization is not critical

Choose Request to Pay when:

You need full control over UX

You want to design custom payment logic

You are building a differentiated product

Both options can coexist within the same business.

While R2P and Checkout use the same underlying payment infrastructure, they differ in who controls the experience.

Dimension	Checkout	Request to Pay (R2P)
Enablement	Hosted	API-only
UX ownership	Cobre	Client
UI/Flow	Pre-built	Fully custom
Payment rails	Same	Same
Speed to market	Faster	More flexible
Best for	Simple integrations	Custom products

Checkout prioritizes simplicity, while R2P prioritizes control and customization.

10. Summary — What Cobre Delivers with Request to Pay

With Request to Pay, Cobre enables:

API-only, business/merchant-owned payment flows
Same local rails as Checkout
Dynamic Bre-B keys and QR codes
Bank and wallet payment links
Full UX flexibility and control
Unified transactions and reconciliation

Cobre Request to Pay empowers businesses to build custom, bank-native payment experiences while relying on Cobre for orchestration, security, and settlement.

Request to Pay (R2P)

API-Driven, Merchant-Owned Payment Experiences#

1. What Cobre Enables with Request to Pay#

2. Payment Rails Available in Request to Pay#

2.1 Bre-B Dynamic Key#

2.2 Bre-B Dynamic QR (EMVCo)#

2.3 PSE#

2.4 Bancolombia Button#

2.4 Nequi Button#

3. Webhook Notifications for Request to Pay#

What Webhooks Enable#

Event-Driven Payment Updates#

How Webhooks Fit into the R2P Flow#

4. Owning the Payment Experience#

5. How R2P Works Conceptually#

6. PSE and Bank Selection (Where Applicable)#

7. Transactions, Reporting & Reconciliation#

8. Typical Use Cases for Request to Pay#

9. When to Choose R2P vs Checkout#

10. Summary — What Cobre Delivers with Request to Pay#

API-Driven, Merchant-Owned Payment Experiences

1. What Cobre Enables with Request to Pay

2. Payment Rails Available in Request to Pay

2.1 Bre-B Dynamic Key

2.2 Bre-B Dynamic QR (EMVCo)

2.3 PSE

2.4 Bancolombia Button

2.4 Nequi Button

3. Webhook Notifications for Request to Pay

What Webhooks Enable

Event-Driven Payment Updates

How Webhooks Fit into the R2P Flow

4. Owning the Payment Experience

5. How R2P Works Conceptually

6. PSE and Bank Selection (Where Applicable)

7. Transactions, Reporting & Reconciliation

8. Typical Use Cases for Request to Pay

9. When to Choose R2P vs Checkout

10. Summary — What Cobre Delivers with Request to Pay