Skip to main content
This page describes the structure of a typical single-use Buy Now, Pay Later (BNPL) program at Marqeta and provides a basis for building your BNPL program using known, successful models from our production customers. A card-creation workflow typically begins at the point of sale (POS), when cardholders submit their purchase and select a payment method. In most scenarios, BNPL customers have a checkout option on merchant websites that trigger this process. When triggered, the process of creating the card begins, followed by the authorization of the newly created card. Authorizing the card finalizes the cardholder’s purchase. When a purchase and an agreement with the financial institution are complete, repayment occurs as described in the contract concluded with the cardholder.
Note
Marqeta is not responsible for this contract between you and your cardholder.

​
Card configuration

Before any card can be ordered, you must determine the card’s behavior using Marqeta’s card products. Each card product consists of a group of cards with its own settings, as well as a feature that allows for different behaviors within the Marqeta platform. The card product’s key feature is the config.card_life_cycle.expiration_offset object, which determines the duration of the card’s validity. Typically, these cards are for one-time use only and are often used within an hour of issue. The card product sets maximum and minimum limits on card spend, which you specify during setup. Cards with this configuration are activated upon creation. Their duration can range between one hour and 30 days, depending on the parameters you select while building your card creation request. The typical configuration process is outlined below. See also the following code sample for reference.
  • activate_upon_issue – For virtual cards, this property is set to true, which reduces the number of required API calls and allows cards to be used immediately.
  • expiration_offset.value – This is the maximum value for a card’s expiration that you can select when creating the card. If no expiration offset is provided when creating the card, then this value is used. The card creation request will be rejected if the card expiration offset is greater than this value.
  • expiration_offset.min_offset.value – This is the minimum value for a card’s expiration, which you can select when creating the card. The card will be rejected if the card expiration offset is less than this value.
JSON
{
  "config": {
    "card_life_cycle": {
      "activate_upon_issue": true,
      "expiration_offset": {
        "unit": "DAYS",
        "value": 30,
        "min_offset": {
          "unit": "HOURS",
          "value": 1
        }
      }
    }
  }
}

​
Virtual card creation

When creating a BNPL virtual card, you must ensure that the cardholder is issued an activated card with spend controls that limit transactions to the required specification within the program’s constraints. You can create cards via Marqeta’s API endpoint /cards/{token}/showpan. Using this endpoint ensures that Marqeta will return the PCI data that is required for processing cardholder purchases. When creating the card, customers can set the expiration offset for this particular card. In the following code sample, the card being created will expire after one hour.
JSON
{
  "expiration_offset": {
    "unit": "HOURS",
    "value": 1,
  }
}
Immediately after creating the card, submit a secondary request to set up spend controls. These spend controls link the lifetime spending of the cardholder to a single transaction (usage_limit = 1), as well as the amount of the purchase (amount_limit = transaction amount). This is known as single-use card creation.
Note
Single-use spend controls apply to the individual cardholder, which means that you can only issue one single-use card per cardholder. You can later adjust this single-use spend control if needed, or if the cardholder reuses the card within the expiration offset.
JSON
{
	"name": "Transaction Single-Use Spend Control",
	"active": true,
	"association": {
    "user_token": "{{ _.user_token }}"
  },
	"approvals_only": true,
	"include_purchases": true,
	"include_withdrawals": false,
	"include_transfers": false,
	"include_cashback": false,
	"include_credits": false,
	"currency_code": "GBP",
	"amount_limit": {{_.transaction_amount}},
	"usage_limit": '1',
	"velocity_window": "LIFETIME"
}

​
Authorization

​
Card creation flow

In a typical BNPL construct, the PAN details of the created card are not visible to the cardholder. Instead, you (as the issuing customer) directly enter the card details in the merchant website. As a result, the end-to-end card creation and authorization flow can be completed within seconds for a frictionless customer experience. After creating the card, you (as the issuing customer) retrieve the details from the Marqeta platform and auto-populate them in the merchant website. Card creation and the approval process are supported by financial contracts between you and the cardholder that determine the repayment method. The merchant processes the transaction and passes the corresponding data through the card network to the Marqeta platform, which then confirms the transaction details. Confirmation is an automated process, and Marqeta will ensure that the transaction amount is less than the velocity control that was established when the card was created.

​
Card verification checks

A merchant might submit a low-amount transaction in order to perform a card verification check. Marqeta will approve this transaction if the merchant submits it as a zero amount. If authorized, this transaction will not impact the velocity control’s usage_limit. On the other hand, if the merchant submits a low-amount transaction instead of a zero-amount card verification check, the transaction amount will count towards the velocity control’s usage_limit. As a general rule, Marqeta prefers merchants to perform zero-amount card verification checks; however, some merchants might not follow this suggestion. You should factor this variability in merchant practice into your cardholder velocity controls. When the pre-checks for the correctness and validity of the transaction are complete successfully, Marqeta initiates the funding of the transaction, reaching out to your JIT gateway for approval of the final transaction. At this point, you must choose whether to approve or decline the transaction, based on the established internal rules of the card product. Prior to this transaction, you should have conducted relevant pre-screening checks. If the transaction is approved, it transitions to a PENDING state, waiting for the clearing event that will complete the transaction. As part of the transaction flow, the merchant might send Marqeta additional events that will ultimately change the transaction’s final amount. These additional events can include advice, reversals, and clearings, which are informative events upon which neither Marqeta nor the issuing program can perform any action. They simply inform the relevant parties that an action has already occurred. For a comprehensive list of events, see Event Types. You must configure processes that allow for fluctuations in the original authorized amount, since such variations are affected by the financial agreement concluded between your issuing program and your cardholder regarding the repayment of specific amounts. Spend controls are applicable only to actionable events within the Marqeta platform. As a result, the only event that is subject to spend controls is the incremental authorization event.
Note
You should consider factoring in a fixed buffering amount for this type of transaction flow. You could also choose not to set a buffering amount, depending on the guidelines established in your risk policies.

​
Updating authorization amounts

​
Increasing authorizations

Use either of the following processes to increase an authorization:
  • Incremental – An actionable event that you can approve or decline, allowing for an increase to the original authorization amount. You can choose to decline incrementals; however, such a decline can negatively affect the cardholder experience. Marqeta therefore recommends allowing for an adjustment of—or addendum to—the original agreement to authorize an increase in funds.
  • Clearing – Merchants might push through multiple clearings or a clearing for an amount higher than the authorized amount.
    • Clearings are informative events that you, as the issuing customer, do not get to approve or decline.
    • As the card network normally charges the issuer for the higher amount, all clearings must be processed by Marqeta and the issuing customer.

​
Reducing authorizations

Use either of the following processes to reduce an authorization:
  • Advice – An authorization advice replaces the previous authorization amount with a lower value. Marqeta will fund the difference between the authorization amount and the advice amount using jit_funding.amount, where the jit_funding.method is equal to the pgfs.authorization.reversal to allow for easier processing of this event.
  • Reversal – Informative events regarding the reduction of an authorization amount.
    • The authorization remains in a PENDING state until it has been fully reversed or cleared.
    • Reversals can be for partial amounts.

​
Card termination

When the transaction is finalized, the card can then be terminated. There are two ways of terminating a card, depending on how the issuing program controls the card status. Marqeta will automatically terminate the card once it has passed its expiration offset. This termination job runs once every 24 hours, so the card will likely remain in an ACTIVE state until the following day. Any other transactions attempted by the cardholder during that time period will be declined, as the card has expired. Even though the automated process ensures that eventually the card will be terminated, you retain full access to the Marqeta API. You can therefore terminate the card if needed, depending on the program’s requirements. Clearings can occur several days after the authorization. You can ensure that the card remains active until the authorization has fully cleared using the manual API method, after the full clearing amount or the appropriate issuer expiration (from Marqeta) has been received.

​
Clearing and settlement

Marqeta processes informative data from the card network that summarizes all transactions where issuer settlement is required. Data is sent to Marqeta in batches over the course of the day. Settlement reports are provided by the card network. Marqeta sends these reports to customers to help with settlement and reconciliation. This part of the flow is fairly standard across all constructs. However, there is also an agreement outside of Marqeta’s area of authority, in which the cardholder agrees to repay the issuing program by installments outside of the Marqeta platform. By default, the Marqeta platform will decline any refund authorizations when a card is in a TERMINATED state. You can however, contact your Marqeta representative to make an amendment that allows for refund authorizations using a terminated card. Such an amendment allows you to process refunds to your cardholders, regardless of the underlying card state as a single-use card. You must honor any offline refunds that Marqeta receives for cards in any state. Offline refunds are clearing events and are already finalized, which affects your settlement position. If a refund on a terminated card is processed, the event’s webhook will list the token of a terminated card. You will also receive the corresponding user token, which can then be used to apply the refund to the cardholder’s account (if the customer still has an account with you).

Related topics

Program ReserveProgram Funding SourcesProgram Balances Settlement2024 Release NotesProgram Gateway Funding Sources