Zero balance workflow

Pismo's zero balance integration offers a fast, simple, and efficient management system for network card transactions. Pismo provides the necessary card management and authorization integration to a card issuer, such as Visa and Mastercard. With this solution, you can manage your customer's balances, credit limits, and lifecycle without going through an extensive integration and certification process.

For more information, see Full balance versus zero balance integration.

Zero balance integration workflow

The basic steps of zero balance integration workflow are:

  1. The user provides a merchant with the card information through any of multiple entry modes, such as contactless, chip, magstripe, or typing the card information in an online transaction gateway.
  2. The merchant's point-of-sale (POS) device or payment gateway formats a message with an authorization request to the acquirer. Acquirers own most POS devices.
  1. The acquirer sends a message to the card network.
  2. The card network sends a message to the processor, the Pismo platform.
  3. The Pismo platform performs a set of validations on the message:
    • stateless (message integrity and consistency, such as PIN, CVV, entry mode, and so on)
      An issuer can also customize some validations, see Customized card validations for a complete list.
  1. If the message is not valid, the Pismo platform replies to the card network declining the transaction.
    If the message is valid, the Pismo platform converts the message to a JSON format and sends it to the card issuer for the issuer to authorize or reject the transaction.
  2. The Pismo platform receives the authorization response from the card issuer.


Card issuer time limit to respond

The Pismo platform sets a time-out limit of 2 seconds for the issuer's authorization response. If Pismo cannot contact the issuer, or the request takes longer than the time-out limit, the transaction is declined. In this case, Pismo sends a callback message to a persistence delivery system (queue) for the card issuer to be aware of it and to take any necessary actions as needed.

  1. The Pismo platform sends back the authorization response to the card network in the pertinent protocol.
  2. The card network sends back the response to the acquirer.
  3. The acquirer sends the message to the merchant.

Simulate an authorization

To simulate a network transaction authorization, see Simulate authorizations. For zero balance integration, you can simulate all scenarios on this page, except clearing/base II.

Card issuer authorization

When utilizing zero balance integration, you need to register your own card issuer endpoint during setup. This endpoint enables you to then send an authorization request that adheres to the standards in the provided API reference. This reference shows the standardized message that the Pismo platform sends to the card issuer.

Below is the sample payload that the Pismo platform sends to the card issuer. The example contains some simulated information in the fields. The missing values depend on the type of authorization request the Pismo platform receives from the card network.

    "id": "99999999-aaaa-aaaa-1111-1234567abcde",
    "entity": "transaction",
    "fields": {
        "mti": "0100",
        "card_id": 1,
        "account_id": 1,
        "amount_transaction": 10.10,
        "amount_local": 10.10,
        "amount_settlement": 2.05,
        "transaction_timestamp": "2021-11-05T16:00:00",
        "processing_code": "000000",
        "payment_card_brand": "Mastercard",
        "currency": "986",
        "merchant_id_code": "599999000009999",
        "merchant_name": "MERCHANT NAME  ",
        "merchant_city": "MERCHANT CITY     ",
        "merchant_state_or_country_code": "USA",
        "merchant_terminal_id": "",
        "atc_chip": "",
        "atc_database": "",
        "cvv_data": "",
        "entry_mode": "10",
        "mcc": "5942",
        "card_type": "PLASTIC",
        "country_code": "",
        "chip_validation": true,
        "postal_code": "99999999",
        "chip_cryptogram_information_data": "",
        "chip_transaction_date": "",
        "chip_transaction_type": "",
        "chip_amount_authorized": "",
        "chip_transaction_currency_code": "",
        "chip_application_interchange_profile": "",
        "chip_terminal_country_code": "",
        "chip_cardholder_verification_method": "",
        "chip_terminal_capabilities": "",
        "chip_amount_other": "",
        "chip_application_transaction_counter": "",
        "cardholder_postal_code": "",
        "transaction_type": "00",
        "nsu": "999999",
        "retrieval_reference_number": "999919319999",
        "authorization_code": "ABC123",
        "response_code": "00",
        "terminal_capability": "2",
        "tvr": "",
        "cvr": "",
        "number_of_installments": 1,
        "network_score": 0,
        "pos_postal_code": "99999999",
        "acquirer_code": "016205",
        "denial_code": "",
        "financial_network_code": "MRW",
        "banknet_reference_number": "ZZZ999",
        "network_transaction_data": "",
        "original_network_data": {}, 
        "cvv_presence": false,
        "password_present": false,
        "account_type": "00",
        "validation_results": [{}]

The expected response from the card issuer for the approved transaction:


The expected response from the card issuer for the declined transaction:


Visa partial authorization

Partial authorization addresses insufficient fund declines at the point-of-sale. It provides an alternative to a declined transaction when the available Visa card or account balance is not sufficient to approve a transaction in full. Instead of a decline, the transaction is approved for a portion of the original amount requested. The remainder of the transaction amount may then be paid by other means using split tender functionality, where applicable.

Partial authorization response

Set the following fields in the partial_approval_info object in the authorization response:

  • local_amount - Amount that was partially approved in the transaction's local currency.
  • settlement_amount- Amount that was partially approved in the reconciliation currency.
  • cardholder_amount- Amount that was partially approved in the cardholder's currency.

Example response

   "is_approved": true,
   "response_code": "10", 
   "limit_amount": null,

   "partial_approval_info": {
       local_amount: 10.0,
       settlement_amount: 2.0,
       cardholder_amount: 8.50

A response_code = "10" means that the transaction was partially approved, and the issuer needs to return the approved amounts fields. When these fields aren't returned or the amounts are negative, Pismo returns the ZBD custom field and response_code = 96.

Related pages

Guide / Card network authorization overview
Guide / Simulate authorizations
API reference / Issuer authorization