"networkToken" in the capabilities array of the request of Charge, Tokenless charge, Pre-authorization or Tokenless pre-authorization.network object with wallet, walletId, isNetworkToken, tmsMaskedCardNumber, tmsLastFourDigits, tmsBin and tmsIntegration, so you can identify that Kushki created the network token. For a full explanation of both ways to use network tokens, see Network Tokens.ℹ️ Availability: Colombia, under Kushki's acquiring. Network token creation is enabled on demand through a commercial agreement. Not every transaction is tokenized this way even with the agreement active: check the networkobject in each response.
⚠️ Supported operations: verification, reauthorization and capture do not support networkTokenincapabilities.
network object in charge and pre-authorization responsesnetwork object now groups two independent sets of fields in a single object: the Card on File fields (scheme, transactionIdentifier), returned when the request includes franchiseTransactionCode in capabilities, and the network token fields, returned when it includes networkToken. You can receive one set, both or none, depending on the values sent in capabilities.from and to with optional brand, country, fraud_type and merchant_id filters, or by transaction identifier, using transaction_arn or transaction_reference. Results are paginated with page and limit.Private-merchant-id header, and use the merchant_id field to scope the query to specific branches.⚠️ Availability: this report is only available for transactions made with VISA and MASTERCARD cards, and only for Kushki's acquiring.
ℹ️ Date range limit: queries are limited to a maximum of 12 months from the current date, and fromandtomust use the exact formatYYYY-MM-DDThh:mm:ss.
"fullResponse": "v3". This version extends the details object in the response with additional subscription data, including validationTicketNumber — the ticket number of the validation charge executed at subscription creation.v3, the Get recurring charge info endpoint also returns validationTicketNumber in its response.⚠️ V3 response stability: The v3response may include new or deprecated fields without prior notice. Always handle unexpected or missing fields gracefully.
accountType): KI (national ID), KP (mobile number), KE (email), KA (alphanumeric alias), KM (merchant code).⚠️ Beta access: Available only for Colombia merchants with the Bre-B processor configured on their MID. To request access, contact your account executive. Sending Bre-B key types without the processor configured returns HTTP 400.
start, end, and size query parameters to scope results to a specific billing period.startDate, endDate, page, and limit body parameters to scope results to a specific period. Authentication via the private-merchant-id header is required.pos_details:pos_user: Device operator username.pos_friendly_name: Friendly display name of the terminal.pos_serial: Device serial number.pos_type: Physical device type. Possible values: COUNTERTOP, MPOS, SMARTPOS, SELF_SERVICE, OTHER.pos_connectivity: Network connectivity type. Possible values: GPRS, WIFI, ETHERNET, DIAL_UP, OTHER.These fields are only returned in card present transactions if they were sent in the original request.