Multiple Updates

New Fields in Transaction Event

On Tuesday, January 28th, the fields original_banknet_reference_number, original_switch_serial_number, and original_transaction_id will be introduced to the event-level network_info within the transaction object. See below for their placement within network_info.

"network_info": {
    "acquirer": {
      ...
    },
    "mastercard": {
      ...
      "original_banknet_reference_number": String | null,
      "original_switch_serial_number": String | null
    },
    "visa": {
      ...
      "original_transaction_id": String | null
    }
}

Definitions

The transaction events mentioned below are described in our Transaction Flow page.

• original_banknet_reference_number - matches the banknet_reference_number of a prior related event. May be populated in authorization reversals, incremental authorizations (authorization requests that augment a previously authorized amount), automated fuel dispenser authorization advices and clearings, and financial authorizations. Applies to dual- and single-message Mastercard transactions.
• original_switch_serial_number - matches the switch_serial_number of a prior related event. May be populated in returns and return reversals. Applies to single-message Mastercard transactions.
• original_transaction_id - matches the transaction_id of a prior related event. May be populated in incremental authorizations, authorization advices, financial authorizations, and clearings. Applies to dual- and single-message Visa transactions.

Each field is populated contingent on the network and the dual- vs single- message system the given transaction event occurs on. If the field is populated by the network, we will pass it through as is, with one exception. If the network populates the original banknet reference number with all zeroes, which signals that no actual reference number could be found, then we will display this as null.

Please consult the official network documentation for more details about these fields and how to use them.

Lithic Python SDK Support Changes

Today, the lithic-python SDK supports passing the following (deprecated) arguments: proxies, transport, and connection_pool_limits.

If you are using one of these arguments and update your httpx after the 0.28.0 version, it will cause the arguments to fail. The recommendation is to pin httpx=0.28.0 until you are able make changes on your side.

On Monday, February 24th, the arguments will be removed from the lithic-python SDK.

The recommended way to configure these is by passing the http_client argument directly.

DPAN Support in Tokenization Endpoints and Events

Every tokenization request creates a unique DPAN, a device-specific token that's generated by the network. Starting on Wednesday, January 15th, the dpanwill be returned in the response for the following:

• Get a card's tokenizations endpoint
• Get a single card tokenization endpoint
• Simulate a card's tokenization endpoint
• Update digital card art for a card tokenization endpoint
• tokenization.updated event

If you have any questions or concerns, please contact us via the HELP link in your Lithic Dashboard.

The Lithic changelog has an RSS feed! To monitor for new update announcements, subscribe with your preferred RSS reader.