--- title: "Create cash-in or cash-out" method: POST path: "/payment-methods/v2/payments" tags: ["Payment methods"] --- # Create cash-in or cash-out `POST /payment-methods/v2/payments` Create a cash-in or cash-out payment operation. The type of operation depends on the processing code (credit for cash-in and debit for cash-out). - For cash-in operations, the processing code must be of credit type. When [creating a processing code](https://developers.pismo.io/pismo-docs/reference/createprocessingcode), ensure that the `balance_impact` is `1` (credit). - For cash-out operations, the processing code must be of debit type. When [creating a processing code](https://developers.pismo.io/pismo-docs/reference/createprocessingcode), ensure that the `balance_impact` is `-1` (debit). With this endpoint, you have the following additional options. - Specify the `authentication` method and details. - Set `pre_authorization` to `true` for operations that require additional confirmation and then call the [Confirm pre-authorized cash-in or cash-out](https://developers.pismo.io/pismo-docs/reference/post-payment-confirm) endpoint. - Set `validation_rules` to control the rules in this flow, such as disabling a rule, changing the response code and denial code, and forcing a rule. Refer to the [Payment methods](https://developers.pismo.io/pismo-docs/docs/payment-methods) and [Payment configurations](https://developers.pismo.io/pismo-docs/docs/payments-configurations) guides for additional information. This endpoint generates a [Platform authorization created](https://developers.pismo.io/events/docs/platform-authorization-platform-authorization-1) event. **Note:** This is a PCI endpoint, use the https://gw-pci.pismolabs.io environment. ## Request body - PaymentsRequest — Request authorization processing for a cash-in or cash-out operation. - `account_id` integer, required — Account ID - `beneficiary_id` string — Beneficiary ID. This ID created when the [Register beneficiary](https://developers.pismo.io/pismo-docs/reference/post-intl-bank-accounts-v1-bank-accounts-beneficiaries) endpoint is called. - `amount` number, double, required — Fee amount. - `currency_code` string — ISO-4217 alphabetic or numeric (3 characters) authorization currency code. For example, either BRL or 986 for Brazilian real. If you don't provide the currency, the platform uses the currency registered in the Pismo hierarchy (first looking at the account, then program, and then Org levels). - `processing_code` string, required — Processing code for the debit transaction. If `split_transaction` is `false` (the default), each installment payment is recorded as one debit transaction equal to the installment amount minus the discount, and `processing_code` is the processing code for that transaction. If `split_transaction` is `true`, each installment payment is recorded as two transactions: a debit transaction for the installment amount and a credit transaction for the discount. In this case, `processing_code` is the processsing code for the debit transaction, and `second_processing_code` is the processing code for the credit transaction. - `tracking_id` string, required — Customer created tracking ID. Must consist of alphanumeric characters (a-z, A-Z, 0-9), hyphens (-), and colons (:), with a length from 1 to 128. The Pismo platform uses this field to implement idempotency and prevent duplicates. - `authentication` Authentication — Authentication object. - `method` string — Authentication method. - `otp` is when the operation needs to be authenticated. - `transaction_signing` is when the operation has been authenticated already but needs to be validated. - `parameters` object — Authentication parameters will vary, depending on type of the method used. - `device_id` string — Device ID. Used in the `otp` authentication method. - `token` string — Authentication token. Used in the `otp` authentication method. - `user_id` string — User ID. Used in the `otp` authentication method. - `hash` string — Value generated at the time of authentication via OTP and intended for authentication via signing. Used in the `transaction_signing` authentication method. - `signing_data` object — Object that contains authorization information provided at time of signing. Used in the `transaction_signing` authentication method. - `description` string — Challenge result - `metadata` string — Any data object with key/value pairs. No limit on length. **Note**: This field must not be used to send Personally Identifiable Information (PII), Payment Card Industry (PCI) data, or any sensitive/regulated information. Metadata fields are intended for operational, non-sensitive data only. For sensitive data, use the specific parameters designed for that purpose. For more information, refer to [Get started with Pismo APIs](https://developers.pismo.io/pismo-docs/reference/get-started-with-pismo-apis#metadata). - `payment_datetime` string, date-time — Date and time of the payment. Specifying a `payment_datetime` value impacts the account balance history.
Notes: - The payment datetime is in ISO 8601 format. - You can backdate payments a maximum of 390 calendar days. You can postdate payments a maximum of 10 calendar days. - `pre_authorization` boolean — If set to `true`, this flag indicates that the operation is pre-authorized and requires additional confirmation. - `validation_rules` ValidationRules — Rules that determine which validations are executed during the payment process.
Available validation rules: - `LEDGER` - `ACCOUNT_STATUS` - `FLEX_CONTROLS` - `RATES`
`force` is only supported for `LEDGER`. `override` is supported for `ACCOUNT_STATUS`, `FLEX_CONTROLS`, and `RATES`. - `authorization_validations` AuthorizationValidations — Contains additional data to be used in the authorization flow. This field is only considered for authorizations. Cancellations and confirmations will retrieve it based on the original authorization. - `is_device_registered` boolean — Indicates whether the device used for the operation is registered according to the financial institution's security policies. - `associated_ids` AssociatedIDs — External IDs used in the authorization flow. - `payment_id` string — External ID associated with the authorization. - `origin_id` string — External ID of the origin of the authorization. - `original_authorization` OriginalAuthorization — This optional field identifies the original authorization to be linked. When this object is provided, both the `id` and `type` fields need to be filled. - `id` integer, required — Original authorization ID in the Pismo platform. - `type` 'NETWORK' | 'PLATFORM', required — Original authorization type. ## Response `200` Request was processed successfully, existing authorization with the corresponding `tracking_id` returned. - V2PaymentsResponse — Response for a cash-in or cash-out operation. - `tracking_id` string, required — Customer created tracking ID. Must consist of alphanumeric characters (a-z, A-Z, 0-9), hyphens (-), and colons (:), with a length from 1 to 128. The Pismo platform uses this field to implement idempotency and prevent duplicates. - `account_id` integer — Account ID - `response_code` string, required — Network two-digit response code. For example: 00 = approve, 51 = insufficient funds, 57 = card not active, 96 = system failure, etc. For more information, see [Validation codes for authorization events](https://developers.pismo.io/pismo-docs/docs/validation-codes-for-authorization-events). If `approve` = `false`, you can use this value to respond to the network. - `denial_code` string — Authorization denial code - `validation_results` object[] - `name` string — Name of the evaluated rule. - `status` 'APPROVED' | 'REJECTED' | 'SKIPPED' — Identifies if the rule was approved, rejected, or skipped during the validation flow. - `reason` string — Status reason why the specific rule was approved, rejected, or skipped. - `description` string — Description of the validation result. - `additional_data` object — Additional data for the validation result. This varies from validation to validation, but every denied validation has the `denial_code` and `response_code` fields. ## Other responses - `201` — Request was processed successfully, new authorization created. - `400` — Bad request - `401` — Access token is missing or invalid. - `409` — Conflict - `422` — Unprocessable request - `500` — Internal server error --- [API](https://skmtc.net/pismo/apis/platform-authentication.md) · [All operations](https://skmtc.net/pismo/apis/platform-authentication/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/pismo/platform-authentication/revisions/935b62e16de4/schema)