--- title: "Returns the transaction response of a non-pending transaction" method: GET path: "/transactions/{shinkansen_id}/response" tags: ["Transactions & Responses"] --- # Returns the transaction response of a non-pending transaction `GET /transactions/{shinkansen_id}/response` ## Request - Base URL: `https://api.shinkansen.finance/v1` - URL: `https://api.shinkansen.finance/v1/transactions/{shinkansen_id}/response` - Auth: API key in header `Shinkansen-Api-Key` Can be used when the participant needs to re-check the response for a given transaction (e.g: if an unexpected error means they lost a response) ## Response `200` The response of a non-pending transaction. - TransactionResponse: Contains the response of a payin transaction - `transaction_type` string, required: Transaction type. Always should be `"payin"` for this type of transaction. - `transaction_id` string, required: UUID Unique identifier of the transaction. Generated by original sender of the payin. - `shinkansen_transaction_id` string, required: UUID Unique identifier of the transaction. Set by Shinkansen on the transaction message. - `shinkansen_transaction_status` 'ok' | 'error', required: Status as reported by Shinkansen. Either `ok` or `error` (Can't be `pending` because that's the status for transactions without a response) - `shinkansen_transaction_message` string, required: Human-readable message further explaining the Shinkansen status. - `response_id` string, required: UUID Unique identifier of the response. Set by Shinkansen on the response message. - `response_status` 'ok' | 'invalid' | 'error_expired' | 'error_debtor_rejected' | 'error_debtor_account_not_found' | 'error_debtor_account_detail_mismatch' | 'error_debtor_account_insufficient_funds' | 'error_debtor_account_over_limits' | 'error_debtor_fi_offline' | 'error_payment_rail_offline' | 'error_creditor_account_over_limits' | 'error', required: Status of the response, reported by the payin operator (or shinkansen if the operator is down): * `ok`: The payin was successful. Note that the money might not be available yet on the destination account. See the Notifications product to know when money is actually credited to your bank account. See also the expected_settlement_date field. * `invalid`: The request failed some validation. * `error_expired`: The payin request expired (typically for expected payments if an `expiration_date` was specified when creating the payin request) * `error_debtor_rejected`: The end user rejected the payment. * `error_debtor_account_not_found`: The origin account doesn't exist * `error_debtor_account_detail_mismatch`: Something is wrong with the origin account details * `error_debtor_account_insufficient_funds`: The origin account doesn't have enough funds to cover the payin amount * `error_debtor_account_over_limits`: The origin account is over the limits set by the debtor bank/institution. Might also indicate lack of funds on some payment rails which don't have separate error codes. * `error_debtor_fi_offline`: The origin bank/institution is offline * `error_payment_rail_offline`: The payment rail is offline. * `error_creditor_account_over_limits`: The destination account is over the limits set by the creditor bank/institution or payment rail. * `error`: Other errors not categorized above. - `response_message` string, required: Human-readable message further explaining the response status. - `expected_settlement_date` string, date: Date when the payin is expected to be settled and funds arrive at the creditor's account. This is the date when the money will be available on the destination account. This is only set when the response status is `ok` and the operator provides this information. Note that the actual settlement amount might be different from the payin amount due to exchange rates, fees, etc. To be notified of the actual settlement event, see the Notifications product. - `additional_info` object: Additional information about the payin. This is only set when the response status is `ok` and the operator provides this information. Typically added for interactive payins where you didn't know much about the debtor when creating the transaction, but the operator can provide more details when the user confirms and authorizes the payin. - `debtor` object: Debtor information. All fields are optional and provided as long as the operator can provide them. - `name` string: Debtor name. The legal name of the legal/natural person sending the funds. - `identification` object: The identifier for a legal or natural person - `id_schema` string, required: Identification schema. See https://docs.shinkansen.tech/docs/tipos-de-identificacion - `id` string, required: The actual identification "number" (but not always just numbers). For `"MXRFC"` schema (Mexican RFCs), it can contain numbers and letters (13 for natural persons, 12 for legal entities). For `"MXCURP"` schema (Mexican CURPs) identifying natural persons, it can contain numbers and letters (18 characters). For `"COCC"`, `"COTI"`, `"CONUIP"`, and `"COCE"` schemas (all identifying natural personal in Colombia), use only numbers. For `"CONIT"` schema (Colombian NITs, for legal entities), also use only numbers. For `"PASS"` schema (Passports, used in Colombia for some accounts in name of foreign natural persons), it can contain numbers and letters (and generally whatever is literally printed as a passport number). For `"CLID"` schema (Chilean RUTs, for legal entities and natural persons) you must use the XXXXXXXX-X format: `^\d{8}[-][0-9kK]$`. See https://docs.shinkansen.tech/docs/tipos-de-identificacion for more details. - `financial_institution` object: The identifier for a financial institution - `fin_id_schema` string, required: Identification schema for financial institution, namely, any participant in Shinkansen Network. Use `"SHINKANSEN"` for Shinkansen's native network ids and full support on any participant and service of the Shinkansen network. Other schemas might be used when interfacing with other networks but they are *not* recommended unless you *really* know what you are doing or have been explicitly instructed to do so by Shinkansen. - `fin_id` string, required: Identification according to schema. When the `"SHINKANSEN"` schema is used (as recommended), this is the ID assigned by Shinkansen to the participant in the network. In the context of the `header`, it refers to the Shinkansen network participant that sends (Sender) or receives (Receiver) the message. In the context of the `transactions`, it refers to the financial institution from which the resources leave or where the resources arrive. The ID assigned by Shinkansen to the financial institution can be found in https://docs.shinkansen.tech/docs/instituciones-financieras. When sending a transaction to Shinkansen, this value must always be SHINKANSEN. When sending a payout order to Shinkansen Treasury, this value must be SHINKANSEN_TREASURY - `account` string: Bank account number of the debtor. - `account_type` string: Account type. See https://docs.shinkansen.tech/docs/tipos-de-cuentas for possible values. - `email` string, email: E-mail of the legal or natural person sending the funds. ## Other responses - `403`: Forbidden (e.g: wrong API Key) - `404`: Transaction id not found or response not found (transaction is pending). --- [API](https://skmtc.dev/shinkansen/apis/payin-transactions-shinkansen-endpoints.md) - [All operations](https://skmtc.dev/shinkansen/apis/payin-transactions-shinkansen-endpoints/llms.txt) - [OpenAPI document](https://skmtc.dev/shinkansen/apis/payin-transactions-shinkansen-endpoints/revisions/208e04fad4a5?raw)