Creating QR Codes

This specification is subject to change, it is Work in Progress. The Colombian EASPBV standard is evolving to support the capabilities of the Bre-B network.

Passport is actively collaborating with industry stakeholders to shape a flexible and robust QR Code integration model for real-time payments.

Overview

To create a QR Code, several preconditions must be met. The QR Code includes merchant identity and context information, which is automatically pulled from previously created resources. This saves you from duplicating data in the QR Code request.

Prerequisites

The information for the QR Code is pulled from a variety of sources:

Customer: The created Customer contains information such as the Merchant Name and Address which provides data such as the name, city, zip code, and country which are mandatory data fields for the QR Code.

Bre-B Key: A created Key for an Account must be stored in a Static or Dynamic QR Code to route Payments to the Merchant over the Bre-B network.

Configuration: Setting other information such as the Merchant Category Code on the Configuration for the Merchant is required as this is another mandatory data field for a QR Code.

API Request: The majority of the information is provided via the Create QR Codes API request and can include mandatory and optional information depending on the intended use case.

Required Tasks

To satisfy the prerequisites, you must complete the following tasks:

StepDescription
1Create Customer a with legal name, address, city, country, and zip code.
2Update the configuration (PATCH) for the Customer to ensure the Merchant information is added.
3Link Account linked to the active customer.
4Create Keys at least one Bre-B Key associated with that account.

Once you finish the steps, you can gather the necessary information for the QR Code from the relevant sources to meet the profile requirements. Use the Create QR Codes API request to get the remaining fields for creating the Static or Dynamic QR Code.

QR Code Creation

To generate the QR Code, you can enhance the information provided above by filling in the necessary fields based on your specific use case.

The tabs below showcase a range of examples illustrating how to generate diverse QR Codes tailored to meet various popular use cases for processing payments. Each example offers insights into the unique requirements and functionalities associated with different payment scenarios.

Static - Print
Dynamic - PoS
Dynamic - ATM
Dynamic - Online

Static QR Code

A Static QR Code contains fixed payment information and does not change once created. It’s typically printed and displayed on a physical medium, such as a sticker, poster, or checkout stand in a merchant's location.

This QR Code type is ideal for environments where the merchant has a direct, in-person interaction with the buyer, such as small vendors or informal retail setups.

  • The buyer scans the QR Code using their mobile banking app.
  • The buyer manually enters the amount and submits the payment.
  • The merchant confirms the payment manually, for example by checking their banking app.

No integration with a Point of Sale system is required, making this a lightweight solution for Bre-B acceptance.

Passport’s PaaS Platform supports multiple implementation paths: either through dedicated merchant accounts or platform-managed flows where you remain in control of the end-to-end payment lifecycle.

Static QR Code Request Example

The example below could be used for a small street vendor wishing to take Bre-B Payments via a Static QR Code that has been printed out on a sticker that is attached to the side of their cart to help Buyers scan to make a Payment.

ParameterDescription
key_idThe unique identifier for the Bre-B key that was created in a previous step for the pre-requisite.
entity_customer_idThe unique identifier of the merchant (Customer).
typeSet to STATIC to indicate this is a static QR Code. (DYNAMIC is an option but in this use case STATIC is correct).
channelSet to MPOS to indicate this is used via a Mobile Point of Sale.
additional_info.transaction_purposeSubmitted within the additional_info object, but specifies what the transaction purpose is, in this example it will be set to SHOPPING
additional_info.transaction.channel_presentation

Submitted within the additional_info object as an optional three digit code that represents the medium used to provide more detail to the channel.

In this example, it was a Printed Sticker (0), that was not used at the registered location of the business (1) and the cashier was present (0) therefore 010 is submitted.

Static QR Code Request Body

Static QR Code
Copy

There are additional optional fields that can be added to the additional_info object to augment the information in the QR Code, explore the endpoint Create QR Codes to learn more about them and what they can be used for.

Static QR Code Response Example

Once the request is submitted, the PaaS Platform combines information from the various sources in order to create the compliant QR Code according to the Colombian EASPBV Industry Specification for QR Codes. The response is provided back to the Developer in a similar format as other Resources.

ParameterDescription
idThe unique id for the QR Code that was created from the POST request that can be used for future retrieval and deletion requests.
qr_code dataThe formatted string for the QR Code that contains the data which can be presented via a digital channel or converted and printed out.
keyAn object to represent the key_value and key_type that was used for creating the QR Code which is also referenced by the key_id
acquirer_network identifierQR Codes will always be issued by VISI who are an authorised issuer by Banco de la República for Bre-B keys.
merchantAn object representing the information relating to the Merchant itself - the name, city, zip code, country and category code
statusIndicates successful creation (ACTIVE).
created_atA timestamp capturing when the QR Code was created successfully.
key_idThe unique id for the Bre-B key that was created in a previous step for the pre-requisite.
customer_idThe unique id for the Customer was that was created in a previous step for the pre-requisite.
typeWhether the developer would like to create a STATIC or DYNAMIC QR code - in this example, the Developer would chose STATIC.
channelStates how the QR Code has been presented by the Merchant to the Buyer - in this example, the Developer would chose MPOS for a Mobile Point Of Sale.
transaction_purposeReturned within the additional_info object, but specifies what the transaction purpose is, in this example it will be set to SHOPPING
channel_presentation

Returned within the additional_info object as an optional three digit code that represents the medium used to provide more detail to the channel.

In this example, it was a Printed Sticker (0), that was not used at the registered location of the business (1) and the cashier was present (0) therefore 010 is submitted.

Static QR Code Response Body

Response - 201 Created
Copy

The QR Code has been created successfully and can then use the returned id as a future reference to retrieve and delete as required. The qr_code_data field contains the encoded string that can be printed out as many times as the Merchant wishes, or use the qr_code_image which is in base64 for ease of use.

The Benefits of the Static QR Code are:

  • Data is fixed - the same key, channel, transaction_purpose and channel_presentation can be printed out and used multiple times over
  • The sticker can be included in a variety of places on the cart to make it easy for the Buyer to scan and interact with
  • There is no complicated integration with a Point of Sale system required to generate and receive Payments
Type to search, ESC to discard
Type to search, ESC to discard
Type to search, ESC to discard

PaaS Platform does not verify that the calculated VAT or INC numbers are correct - we do not contain a list of all appropriate added taxes or charges that should be added to every type of transaction in Colombia.

Nor do our Sponsor Bank partners take any liability for ensuring these details are correct - it is up to the Developer to ensure that the appropriate fees and add-ons are calculated as part of the accounting for processing sales.

Type to search, ESC to discard
Type to search, ESC to discard
Type to search, ESC to discard