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.
- 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:
- Remove funds from an account; instead, consult Creating an Adjustment.
- Transfer funds from one account to another in the same program; instead, use the Creating an Internal Transfer procedure.
Also see Payments vs. adjustments in the Creating an Adjustment guide.
- 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 the system is configured to assess a 15-cent fee for retail loads (otype RL), calling Create Payment would produce these transactions:
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.
Prior to creating a payment, you can call the Verify Account endpoint and pass the intended payment otype in the
loadType parameter. The endpoint returns these values:
max_load_amount— The maximum amount configured for the payment type.
balance— The available balance (open to buy) on the account.
account_status— The current account status. Only some statuses permit payments.
Using these values you can determine whether to call Create Payment or whether to notify the account holder that the payment cannot be made at this time.
This table explains parameters for the Create Payment endpoint.
|The receiving account number.|
|The amount to transfer, as a decimal or whole number.|
|You determine valid values in cooperation with Galileo.|
|Your description of the transaction, if you provide one.|
|Unique identifier for the location where the payment occurs.|
|If the location type is |
|If a fee is assessed, pass the amount of the fee for informational purposes. To assess the actual fee, use the Assess Fee endpoint.|
|Merchant and store parameters||Used by some retail locations that load funds onto cards.|
|Amount of the payment to hold.|
|When to expire the hold.|
|A description for the hold.|
|An alternate ID for the hold.|
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 flowchart shows the logical progression of the Create Payment endpoint. The actual sequence of events in the Galileo system may vary.
- You send the Create Payment request.
- Galileo performs a number of preliminary checks. Failures return the status codes shown in the diagram.
- Galileo verifies that the payment is within load limits for the receiving account. If it is not, the endpoint returns
- The endpoint sends
- If the
holdDaysparameter was populated, Galileo waits until the hold days expire.
- Galileo creates the transaction by crediting the receiving account. If a load limit was violated, Galileo creates a payment for a partial amount.
- Galileo sends Transaction Events webhook
BPMT: pmtfor the receiving account.
When initiating a transaction with the Program API, the
transactionIdfrom 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 RDF as
EXTERNAL TRANSACTION ID, and in the Events API webhook messages as
You can update the hold days on a payment that has not been processed. The payment must be in
status: R (ready to process) to be updated.
This table explains parameters for the Update Payment endpoint.
|The receiving account number in the original API call.|
|The payment ID for the payment to be updated. This value is returned as |
|Number of days to hold the payment. Pass |
The logical progression of the Update Payment endpoint is as follows:
- Galileo looks for the payment ID. If it cannot find it, Galileo returns
- Galileo verifies that the payment is in
status: R. If it is not, Galileo returns
- Galileo updates the number of days to hold the payment. If the updated value is 0, Galileo posts the payment immediately.
Although the Program API has a Reverse Payment endpoint, Galileo recommends that you not use it to reverse a payment, because of the way that endpoint handles transaction codes. If you use the Reverse Payment endpoint, the reversed transaction will not have a transaction code that indicates that it is the reversal of a previous transaction.
Instead, when you design your funds-flow schema with Galileo, make sure that you have an otype that designates a reversal for each type of payment. Using the Create Adjustment endpoint, reverse the original payment by using the corresponding reversal otype for
You can view a record of payments deposited to a customer account using any endpoint that returns posted transactions:
There is a delay of several seconds before a payment appears in a customer’s transaction history and account overview.
Consult Finding Transaction Data to see where else payments are visible.
Updated about 2 months ago