# Transactions Use these operations to: - set up payment instruments for payments - authorize and hold funds - capture funds - make payments - make payouts - refund transactions. ## Ready to pay - [POST /ready-to-pay](https://www.rebilly.com/docs/dev-docs/api/transactions/postreadytopay.md): Retrieves available payment methods for a specific transaction or purchase. The order in which the payment methods are displayed to the customer should be the same as the order in the response. The list of payment methods is generated from available gateway accounts and the last matched adjust-ready-to-pay action on the ready-to-pay-requested event. If no rules match for the specific request, all methods supported by the gateway accounts are sent. To invert this behavior, place an all matching rule at the end of the ready-to-pay-requested event in the rules engine, and include an empty paymentMethods property for the adjust-ready-to-pay action. For more information, see Update event rules and Gateway accounts. ## Create a transaction - [POST /transactions](https://www.rebilly.com/docs/dev-docs/api/transactions/posttransaction.md): Creates a transaction of type sale, authorize or setup. Use this operation for the following transactions. #### Real-time decision and response In this transaction, you send a request and inspect the result of the response for approved or declined. #### User approval/interaction required In this transaction, user approval is required to complete the transaction. User approval generally requires the user to interact with a third party, and is common in many transactions for alternative methods. For example, PayPal requires user permission to complete a payment or to accept a billing agreement. Payment cards may also require user approval for 3D secure authentication. If approval is required, you receive a response with a result value of unknown and a status value of waiting-approval. The _links property of the response has a link for the approvalUrl. Open the approvalUrl in an iframe or in a pop. A pop is a better workflow for mobile devices. ## Retrieve transactions - [GET /transactions](https://www.rebilly.com/docs/dev-docs/api/transactions/gettransactioncollection.md): Retrieves a list of transactions. ## Retrieve a transaction - [GET /transactions/{id}](https://www.rebilly.com/docs/dev-docs/api/transactions/gettransaction.md): Retrieves a transaction with a specified ID. ## Update a transaction - [PATCH /transactions/{id}](https://www.rebilly.com/docs/dev-docs/api/transactions/patchtransaction.md): Updates the custom fields of a transaction with a specified ID. ## Create a credit transaction - [POST /payouts](https://www.rebilly.com/docs/dev-docs/api/transactions/postpayout.md): Creates a transaction of type credit. ## Query a transaction - [POST /transactions/{id}/query](https://www.rebilly.com/docs/dev-docs/api/transactions/posttransactionquery.md): Queries a transaction with a specified ID. The query interacts with the related gateway account to obtain the result, amount, and currency. If after analysis, the transaction must be updated, see Update a transaction status. ## Update a transaction status - [POST /transactions/{id}/update](https://www.rebilly.com/docs/dev-docs/api/transactions/posttransactionupdate.md): Updates the status of a transaction with a specified ID to completed, with a specified result and optional currency and amount values. ## Refund a transaction - [POST /transactions/{id}/refund](https://www.rebilly.com/docs/dev-docs/api/transactions/posttransactionrefund.md): Refunds a transaction with a specified ID. The refund is in the same currency as the original transaction. ## Retrieve payout requests - [GET /payout-requests](https://www.rebilly.com/docs/dev-docs/api/transactions/getpayoutrequestcollection.md): Retrieves a list of payout requests. Filter by: id, customerId, websiteId, batchId, status, blocked, blockReason, createdTime, updatedTime. ## Create a payout request - [POST /payout-requests](https://www.rebilly.com/docs/dev-docs/api/transactions/postpayoutrequest.md): Creates a payout request. In the response, the selectPaymentInstrumentUrl field is used to redirect the customer to select a preferred payment instrument. After a payment instrument is selected, the customer is redirected to the selectedPaymentInstrumentRedirectUrl value. > Important: The selected payment gateway must be configured to support payout requests. > For more information, see the readyToPayoutInstruction field. ## Retrieve a payout request - [GET /payout-requests/{id}](https://www.rebilly.com/docs/dev-docs/api/transactions/getpayoutrequest.md): Retrieves a payout request with a specified ID. ## Upsert a payout request - [PUT /payout-requests/{id}](https://www.rebilly.com/docs/dev-docs/api/transactions/putpayoutrequest.md): Creates or updates (upserts) a payout request with a specified ID. ## Update a payout request - [PATCH /payout-requests/{id}](https://www.rebilly.com/docs/dev-docs/api/transactions/patchpayoutrequest.md): Updates a payout request with a specified ID. Use this operation to update the status, description, and blocked state. ## Cancel a payout request - [POST /payout-requests/{id}/cancel](https://www.rebilly.com/docs/dev-docs/api/transactions/postpayoutrequestcancellation.md): Cancels a payout request with a specified ID. ## Request a payout request split - [POST /payout-requests/{id}/split](https://www.rebilly.com/docs/dev-docs/api/transactions/postpayoutrequestsplit.md): Splits a pending payout request into two or more separate requests. Provide an array of at least two amounts; one new payout request is created per amount. The sum of the amounts must equal the original payout request amount. The original request transitions to the split status. This operation returns the newly created payout requests. ## Retrieve associated payment instruments - [GET /payout-requests/{id}/payment-instruments](https://www.rebilly.com/docs/dev-docs/api/transactions/getpayoutrequestpaymentinstruments.md): Retrieves the payment gateway and a list of payment instruments that are associated with a payout request with a specified ID. ## Retrieve associated payment instruments - [GET /payout-requests-v2/{id}/payment-instruments](https://www.rebilly.com/docs/dev-docs/api/transactions/getpayoutrequestv2paymentinstruments.md): Retrieves the payment gateway and a list of payment instruments that are associated with a payout request with a specified ID. ## Retrieve payout request allocations - [GET /payout-request-allocations](https://www.rebilly.com/docs/dev-docs/api/transactions/getpayoutrequestallocationcollection.md): Retrieves a list of payout request allocations. ## Create a payout request allocation - [POST /payout-request-allocations](https://www.rebilly.com/docs/dev-docs/api/transactions/postpayoutrequestallocation.md): Creates an allocation for a payout request. When an allocation is created, the payout request transitions to the in-progress status, and the allocation starts in the pending status. The allocation transitions to the processing status when payment processing begins. ## Create an automatic payout request allocation - [POST /payout-request-allocations/auto](https://www.rebilly.com/docs/dev-docs/api/transactions/postpayoutrequestautoallocation.md): Creates an automatic payout request allocation using system-selected parameters. Only the payout request ID is required; all allocation details are determined automatically. When an allocation is created, the payout request transitions to the in-progress status, and the allocation starts in the pending status. The allocation transitions to the processing status when payment processing begins. ## Retrieve a payout request allocation - [GET /payout-request-allocations/{id}](https://www.rebilly.com/docs/dev-docs/api/transactions/getpayoutrequestallocation.md): Retrieves a payout request allocation with a specified ID. ## Update allocation status - [PATCH /payout-request-allocations/{id}](https://www.rebilly.com/docs/dev-docs/api/transactions/patchpayoutrequestallocation.md): Updates the status of a payout request allocation with a specified ID. Only the processing and canceled statuses can be set with this operation. The processing status transitions an allocation from pending when payment processing begins. The canceled status stops the allocation before it is processed. The completed and failed statuses are set automatically during transaction processing. Allocations are always created in the pending status. ## Initiate processing of allocations - [POST /payout-request-allocations/process](https://www.rebilly.com/docs/dev-docs/api/transactions/postpayoutrequestallocationsprocess.md): Initiates the processing of one or more payout request allocations. Only allocations with status pending are processed. Each allocation is processed by creating a transaction. ## Retrieve payout request batches - [GET /payout-request-batches](https://www.rebilly.com/docs/dev-docs/api/transactions/getpayoutrequestbatchcollection.md): Retrieves a list of payout request batches. ## Create a payout request batch - [POST /payout-request-batches](https://www.rebilly.com/docs/dev-docs/api/transactions/postpayoutrequestbatch.md): Creates a batch of payout requests for batch processing. The batch links multiple payout requests together so they can be auto-allocated and processed together. Each payout request can be assigned to only one batch. If any of the specified payout requests are already included in another batch, a 409 Conflict error is returned. Both approaches are limited to a maximum of 1000 payout requests per batch. Two mutually exclusive approaches are supported: - Explicit IDs: Provide an array of payout request IDs in the payoutRequestIds field. - Filter-based: Provide a filter string to select payout requests that match the specified criteria at execution time. Payout requests that are already included in a batch are automatically excluded from the filter results. If more than 1000 payout requests match the filter, only the oldest 1000 are included in the batch, sorted by creation time. To view the number of matching items before creating the batch, use the Preview payout request batch filter results operation. ## Retrieve a payout request batch - [GET /payout-request-batches/{id}](https://www.rebilly.com/docs/dev-docs/api/transactions/getpayoutrequestbatch.md): Retrieves a payout request batch with a specified ID. ## Update a payout request batch - [PATCH /payout-request-batches/{id}](https://www.rebilly.com/docs/dev-docs/api/transactions/patchpayoutrequestbatch.md): Partially updates a payout request batch with a specified ID. Use this operation to update the description and allocation order. ## Allocate batch payout requests automatically - [POST /payout-request-batches/{id}/auto-allocate](https://www.rebilly.com/docs/dev-docs/api/transactions/postpayoutrequestbatchautoallocate.md): Creates allocations automatically for all payout requests in the batch using the auto-allocation algorithm. Each payout request is processed independently. ## Approve payout requests in a batch - [POST /payout-request-batches/{id}/approve](https://www.rebilly.com/docs/dev-docs/api/transactions/postpayoutrequestbatchapprove.md): Approves all payout requests in a specified batch. Each payout request is processed independently. Only payout requests with a status of ready can be approved. ## Block batch payout requests - [POST /payout-request-batches/{id}/block](https://www.rebilly.com/docs/dev-docs/api/transactions/postpayoutrequestbatchblock.md): Blocks all payout requests in a specified batch. Each payout request is processed independently. ## Preview payout request batch results - [GET /payout-request-batches/preview](https://www.rebilly.com/docs/dev-docs/api/transactions/getpayoutrequestbatchpreview.md): Retrieves aggregate information for the payout requests that match a specified filter. If more than 1000 payout requests match the filter, only the oldest 1000 are included in the preview. ## Retrieve a payout request (v2 temporary endpoint) (deprecated) - [GET /payout-requests-v2/{id}](https://www.rebilly.com/docs/dev-docs/api/transactions/getpayoutrequestv2.md): Retrieves a payout request with a specified ID. ## Customer redirected offsite - [POST customer-redirected-offsite](https://www.rebilly.com/docs/dev-docs/api/transactions/customer-redirected-offsite.md) ## Customer returned - [POST customer-returned](https://www.rebilly.com/docs/dev-docs/api/transactions/customer-returned.md) ## Gateway account requested - [POST gateway-account-requested](https://www.rebilly.com/docs/dev-docs/api/transactions/gateway-account-requested.md) ## Offsite payment completed - [POST offsite-payment-completed](https://www.rebilly.com/docs/dev-docs/api/transactions/offsite-payment-completed.md) ## Payout request canceled - [POST payout-request-canceled](https://www.rebilly.com/docs/dev-docs/api/transactions/payout-request-canceled.md) ## Payout request created - [POST payout-request-created](https://www.rebilly.com/docs/dev-docs/api/transactions/payout-request-created.md) ## Payout request fulfilled - [POST payout-request-fulfilled](https://www.rebilly.com/docs/dev-docs/api/transactions/payout-request-fulfilled.md) ## Payout request modified - [POST payout-request-modified](https://www.rebilly.com/docs/dev-docs/api/transactions/payout-request-modified.md) ## Ready to pay requested - [POST ready-to-pay-requested](https://www.rebilly.com/docs/dev-docs/api/transactions/ready-to-pay-requested.md) ## Risk score changed - [POST risk-score-changed](https://www.rebilly.com/docs/dev-docs/api/transactions/risk-score-changed.md) ## Transaction amount discrepancy found - [POST transaction-amount-discrepancy-found](https://www.rebilly.com/docs/dev-docs/api/transactions/transaction-amount-discrepancy-found.md) ## Transaction declined - [POST transaction-declined](https://www.rebilly.com/docs/dev-docs/api/transactions/transaction-declined.md) ## Transaction discrepancy found - [POST transaction-discrepancy-found](https://www.rebilly.com/docs/dev-docs/api/transactions/transaction-discrepancy-found.md) ## Transaction process requested - [POST transaction-process-requested](https://www.rebilly.com/docs/dev-docs/api/transactions/transaction-process-requested.md) ## Transaction processed - [POST transaction-processed](https://www.rebilly.com/docs/dev-docs/api/transactions/transaction-processed.md) ## Transaction reconciled - [POST transaction-reconciled](https://www.rebilly.com/docs/dev-docs/api/transactions/transaction-reconciled.md) ## Transaction timeout resolved - [POST transaction-timeout-resolved](https://www.rebilly.com/docs/dev-docs/api/transactions/transaction-timeout-resolved.md) ## Waiting gateway transaction completed - [POST waiting-gateway-transaction-completed](https://www.rebilly.com/docs/dev-docs/api/transactions/waiting-gateway-transaction-completed.md) ## Autodeposit lookup performed - [POST autodeposit-lookup-performed](https://www.rebilly.com/docs/dev-docs/api/transactions/autodeposit-lookup-performed.md)