Creating a Payment

This guide describes the procedure to move funds into a customer account, make payment reversals, and update payment hold days using the Create Payment, Reverse Payment, and Update Payment endpoints.

📘

Note

Galileo uses the term "payment" to refer to funds that are deposited into a customer account by the Create Payment endpoint and by other internal processes.

Follow this procedure to:

• Move funds into a customer account at a time other than account creation, such as when a customer deposits a paper check, cash, or receives a loan.
• Test whether funds can be deposited into a customer account.
• Reverse a payment and check for any reversal fees.
• Update the hold days for a pending payment.

Do not follow this procedure to:

• Transfer funds from one account to another in the same program; instead, use the Creating an Internal Transfer procedure.

Result of calling Create Payment

• The specified amount is credited to the receiving account.
• If configured, a fee is assessed to the sending (or sometimes receiving) account.

The transaction types for deposits using the Create Payment endpoint depend on the value in the type parameter. For example, if a $100.00 retail load is made to the receiving account PRN 77777, and a 15-cent fee is assessed for retail loads, calling Create Payment may produce these transactions:

📘

Note

When initiating a transaction with the Program API, the transactionId from the API request is copied to the external transaction ID field of all transactions that result from the request. The external transaction ID is available in the responses to transaction-retrieval Program API requests as external_trans_id, in the Posted Transactions RDFRDF - Raw data file. Once per day Galileo sends you RDFs that contain a list of all of your previous day's transactions and all of your current customers. Compare the RDFs with your own records and if there are discrepancies, treat the RDFs as authoritative. as EXTERNAL TRANSACTION ID, and in the Events API webhook messages as ext_trans_id.

Result of calling Reverse Payment

The result of the original Create Payment call is undone, meaning that:

• The receiving account is debited the original amount.
• If applicable, the fee is reversed back to the account on which it was assessed.
• If configured, a reverse payment fee is assessed on the receiving account.

📘

Note

For most payment reversals, Galileo recommends using the Create Adjustment endpoint instead of Reverse Payment. See Reversing payments and adjustments in the About Adjustments guide for an explanation.

When reversing a payment, the transactions are recorded as adjustments and the fee is a fee with the sign reversed.

Result of calling Update Payment

The hold days for the original Create Payment call are updated, meaning that:

• Previously configured hold days for the product are replaced with the specified number.
• If the number of hold days is changed to zero, the hold is removed.

Parameters

This table explains parameters for the Create Payment endpoint.

When you populate the hold-related parameters, Galileo returns a hold_id that you can retrieve using the Get Hold History endpoint. To manually expire a hold created in this way, use the Expire Hold endpoint.

This table explains parameters for the Reverse Payment endpoint.

This table explains parameters for the Update Payment endpoint.

Create payment workflow

This flowchart shows the logical progression of the Create Payment endpoint. The actual sequence of events in the Galileo system may vary.

1. You send the Create Payment request.
2. Galileo performs a number of preliminary checks. Failures return the status codes shown in the diagram. Consult the Status codes table for next steps.
3. Galileo verifies that the payment is within load limits for the receiving account. If it is not, Galileo returns status: 408-01.
4. Galileo sends the response status: 0 and creates the transaction by crediting the receiving account.
5. Galileo sends Transaction Events webhook BPMT: pmt for the receiving account.

Payment reversal workflow

The logical progression of the Reverse Payment endpoint is as follows:

1. The Galileo system looks for the transaction ID that matches the original Create Payment request.
2. The Galileo system verifies that there are sufficient funds for payment reversal in the account. If there are not, Galileo returns status: 411-01.
3. The Galileo system reverses the payment so that it is debited from the account.

Payment update workflow

The logical progression of the Update Payment endpoint is as follows:

1. The Galileo system looks for the transaction ID that matches the original Create Payment endpoint.
2. Galileo looks for the payment ID that matches the original Create Payment request. If it does not, Galileo returns status: 533-01.
3. Galileo verifies that the payment is set to status: R. If it is not, Galileo returns status: 533-02.
4. The Galileo system updates the number of days to hold the payment.

Sample endpoint request and response

Consult the Create Payment, Reverse Payment, and Update Payment endpoints to see how to build the API request and to see the response schema.

Status codes

Create payment status codes

Reverse payment status codes

Update payment status codes

Get payment history

You can view a record of payments deposited to a customer account using the Get Payment History endpoint. You can also use the endpoints that retrieve a comprehensive list of transactions, such as Get Account Overview or Get Transaction History.