Real-Time Funding Transaction Examples

This page contains examples of different types of real-time funding (RTF) transactions. For an explanation of real-time funding see About Real-Time Funding. Also see About Card Transactions.

These examples show the entries that are written to the ledger for different transaction types. The tables combine the activity for both the RTF funding and RTF spending accounts. For all examples the following is true:

• 3333333 — PRN of the RTF funding account
• 7777777 — PRN of the RTF spending account
• The source_id for all adjustments refers to the adj_id in the adjustments table.
• The RTF funding account contains 1000.00 as a beginning balance.
• The RTF spending account contains 0.00 as a beginning balance.

Examples

• Conventional purchase
• Reversal without settlement
• Reversal with settlement
• Merchant credit (Maestro)
• Merchant credit (Mastercard credit)
• Gas pump
• Incremental authorization
• Partial reversal on authorization
• Force post
• Incremental clearing

Conventional purchase

A Mastercard cardholder makes a $35 purchase on 13 Jul 2023 at 9:00 am.

• The top row shows the transfer of funds out of the RTF funding account. The source_id refers to the entry in the adjustments table (adj_id).
• The second row shows the transfer of funds into the RTF spending account.
• The third row shows the approved authorization amount. A 35.00 hold is placed on the RTF spending account, so the available balance is 0.00. Between the time that the 35.00 is moved into the RTF spending account and the hold is placed, the amount is locked, so the 35.00 cannot be spent by another process.
• The fourth and fifth rows show the settlement time, when the authorization hold is backed out and the settlement is posted to the RTF spending account.

For instructions on simulating this type of transaction see Perform transactions in Testing Real-Time Funding in CV.

Reversal without settlement

The cardholder makes a $45 purchase on 12 Aug 2023 at 8:00 pm, and it is reversed an hour later. The reversal happens before the transaction clears, so there is no settlement. The network is Visa. Most authorization reversals follow this pattern.

• The first two rows show the transfer from the RTF funding account to the RTF spending account.
• The third row shows the approved authorization amount. A 45.00 hold is placed on the RTF spending account, so the available balance is 0.00.
• The fourth row shows the reversal an hour later. Galileo reverses out the 45.00 hold, so the available balance is 45.00. For this transaction, the prior_id (reversal ID) would be 333000.
• The fifth and sixth rows show that the 45.00 is immediately transferred back to the RTF funding account.
• The seventh and eighth rows show the expiry of the authorization as well as the reversal seven days later.

For instructions on simulating this type of transaction see Authorization reversal in Simulating Card Transactions.

Reversal with settlement

The cardholder makes a $45 purchase on 12 Aug 2023 at 8:00 pm, and it is reversed an hour later. The network sends the reversal in the settlement file. The network is Visa. An authorization reversal followed by a settlement is not a common event.

• The first two rows show the transfer from the RTF funding account to the RTF spending account.
• The third row shows the approved authorization amount. A 45.00 hold is placed on the RTF spending account, so the available balance is 0.00.
• The fourth row shows the reversal an hour later. Galileo reverses out the 45.00 hold, so the available balance is 45.00. For this transaction, the prior_id (reversal ID) would be 333000.
• The fifth and sixth rows show that the 45.00 is immediately transferred back to the RTF funding account.
• The seventh row shows the settlement from the daily batch file, which arrives before the authorization would have expired. The settlement triggers the expiration of the reversal, in the eighth row.

Merchant credit (Maestro)

The cardholder makes a $100 purchase on 3 Nov 2023 at 11:00 am. A week later, the cardholder returns the item for a full refund. The transaction settled before the item was returned. The network is Mastercard Maestro (debit). A Visa merchant credit (credit or debit network) follows the same process.

• The first two rows show the transfer from the RTF funding account to the RTF spending account.
• The third row shows the approved authorization amount. A 100.00 hold is placed on the account, so the available balance is 0.00.
• The fourth and fifth rows show the transaction being backed out and settled.
• The sixth row shows the advice for the merchant credit. However, the merchant credit is not posted to the account at this time.
• The seventh, eighth, and ninth rows show the arrival of the merchant credit in the batch settlement file. Galileo creates a new authorization and backout entry before posting the credit.
• The tenth and eleventh rows show the 100.00 being moved immediately back into the RTF funding account.

Merchant credit (Mastercard credit)

This is exactly the same scenario as above only using Mastercard Banknet (credit). Galileo processes Mastercard Banknet merchant credits as adjustments. The cardholder makes a $100 purchase on 3 Nov 2023 at 11:00 am. A week later, the cardholder returns the item for a full refund.

• The first two rows show the transfer from the RTF funding account to the RTF spending account.
• The third row shows the approved authorization amount. A 100.00 hold is placed on the RTF spending account, so the available balance is 0.00.
• The fourth and fifth rows show the transaction being backed out and settled.
• The sixth row shows the merchant credit, which arrived at Galileo in the batch settlement file that Mastercard sent Galileo. Galileo processes the merchant credit as an adjustment.
• The seventh and eighth rows show the credit being moved out of the RTF spending account back to the RTF funding account.

Gas pump

The cardholder dispenses $50 worth of gas at a gas pump on 3 Jul 2023 at 10:00 am. There is a $75 upcharge for gas purchases. The network is Mastercard Maestro.

• The first and second rows show the amount of the preauthorization being moved from the RFT funding account into the RTF spending account.
• The third row shows the approved authorization amount. A 75.00 hold is placed on the RTF spending account, so the available balance is again 0.00.
• The fourth and fifth rows show the preauthorization hold being backed out and replaced by the –50.00 completion. Galileo replaces the 75.00 hold with a 50.00 hold, leaving 25.00 in the RTF spending account.
• The sixth and seventh rows show the 25.00 being moved immediately from the RTF spending account back into the RTF funding account. The trans_codes are ADSY/ADFY because completions arrive at Galileo through the authorization stream.
• The eighth and ninth rows show the 50.00 completion hold being backed out and settled.

For instructions on simulating this type of transaction see Five-step sequence in Simulating Card Transactions.

Incremental authorization

A cardholder calls a ride-share service through its app, and the cost of the proposed destination is $25. The app authorizes the transaction at 9:00 am. After arriving at the first destination 20 minutes later, the cardholder requests a second destination for $15, and then after arriving at the second destination 30 minutes later, requests a third, for $10.

• The first and second rows show the amount of the authorization being moved from the RFT funding account into the RTF spending account.
• The third row shows the approved authorization amount. A 25.00 hold is placed on the RTF spending account, so the available balance is again 0.00.
• The fourth row shows the 25.00 being backed out because Galileo received an incremental authorization request.
• The fifth and sixth rows show the additional 15.00 being moved from the RTF funding to the RTF spending account.
• The seventh row is the –40.00 incremental authorization request. Galileo places a 40.00 hold on the RTF spending account, so the available balance is again 0.00.
• The eighth row shows the 40.00 hold being backed out because Galileo received another incremental authorization request.
• The ninth and tenth rows show the additional 10.00 being moved from the RTF funding to the RTF spending account.
• The eleventh row is the –50.00 incremental authorization request. Galileo places a 50.00 hold on the RTF spending account, so the available balance is again 0.00.
• The last two rows show the 50.00 hold being backed out and settled. Notice that the auth_id corresponds to the last authorization in the series.

Partial reversal on authorization

A cardholder goes to an agency to rent a car. The agency obtains a $500 preauthorization. The next day, the cardholder returns the car, and the bill comes to $60. The network is Mastercard Banknet (credit).

• The first and second rows show the amount of the authorization being moved from the RFT funding account into the RTF spending account.
• The third row shows the approved preauthorization amount. A 500.00 hold is placed on the RTF spending account, so the available balance is again 0.00.
• The fourth row shows the preauthorization reversal for 440.00. The available balance is 440.00.
• The fifth and sixth rows show the reversal amount being moved back from the RTF spending account to the RTF funding account.
• The seventh row shows the expiry of the 440.00 reversal, which is triggered by the arrival of the batch settlement file.
• The eighth and ninth rows show Galileo backing out the original 500.00 hold and posting –60.00 to the account.

Force post

A cardholder makes a $15 purchase at a store. Technical problems prevent the merchant from getting an authorization at sale time, so the next day the merchant sends a force posting in the settlement batch file.

• When Galileo receives a settlement for a transaction that has no corresponding authorization, Galileo creates an authorization, backs it out, and settles it at the same time. The third, fourth, and fifth rows show this process.
• The first and second rows show the transaction amount being moved from the RTF funding account to the RTF spending account before the authorization is created.

For instructions on simulating this type of transaction see Force-post in Simulating Card Transactions.

Incremental clearing

A cardholder purchases three items from three different third-party vendors on the same online store. The items are for $150, $75, and $175. The online merchant obtains preauthorization for $400, and then each item is cleared separately when the vendors ship them.

• The first and second rows show the amount of the authorization being moved from the RFT funding account into the RTF spending account.
• The third row shows the approved preauthorization amount. A 400.00 hold is placed on the RTF spending account, so the available balance is again 0.00.
• The fourth and fifth rows show the first settlement. Galileo backs out 150.00 of the hold and posts –150.00 to the account. The remaining hold is for 250.00.
• The sixth and seventh rows show the second settlement. Galileo backs out 75.00 of the hold and posts –75.00 to the account. The remaining hold is for 175.00.
• The eighth and ninth rows show the last settlement. Galileo backs out the remaining hold and posts –175.00 to the account.

---