Common Transaction Scenarios

This page describes the following transaction message sequences by adding possible real-life scenarios. See Common message sequences for a bigger list of sequence possibilities.

The following happy path scenarios demonstrate a single auth and clear event, or two discrete ("dual") messages for auth and clear:

• Single auth/clear request sequence: AuthorizationAndClearEvent
• Dual auth/clear request sequence: AuthorizationEvent followed by a ClearingEvent

Scenario (debit card): A cardholder goes to the corner store and buys a loaf of bread with their debit card.

The transaction lifecycle for this scenario might occur as follows:

1. The merchant sends a single authorization and clear request to the network for $5.
2. Highnote interprets the message as a single AuthorizationAndClearEvent for the total $5.

Scenario (credit card): A cardholder goes to the supermarket and buys a bagful of groceries with their credit card.

The transaction lifecycle for this scenario might occur as follows:

1. The merchant sends an authorization request to the network for $50.
2. Highnote interprets the message as a single AuthorizationEvent for the total $50.
3. The merchant charges the cardholder $50 for the total amount and submits a capture request to the network.
4. Highnote interprets the message as a ClearingEvent for the total $50.

Scenario (custom tip): A cardholder takes the family to dinner at their favorite burger joint where they eat $100 worth of burgers and fries. When the bill comes, the cardholder adds a $20 tip.

The transaction lifecycle for this scenario might occur as follows:

1. The merchant brings the bill, gets the cardholder's card, and sends a pre-authorization request to Highnote for $100.
2. Highnote interprets the message as an AuthorizationEvent and places a hold for $100 on the cardholder's financial account.
3. The merchant returns the card and cardholder adds a $20 tip.
4. The merchant charges the cardholder $120 for the total amount and submits a capture request to the network.
5. Highnote interprets the message in two parts: (a) as a second AuthorizationEvent for the incremental $20 (which puts another $20 hold on the cardholder's financial account), and then (b) as a ClearingEvent for the total $120.

Scenario (hotel stay): A cardholder books a hotel (which requires a pre-authorization), incurs additional additional costs (which requires an incremental authorization), and then has a release of the unspent authorized "overage" amount (which requires a reversed authorization).

Check-in: A cardholder arrives at their hotel for a 4-night business trip. At check-in, the hotel processes a pre-authorization of an estimated $1,000 to cover the room rate of $200 per night, plus potential incidentals. This creates a temporary hold on $1,000 of the cardholder's available credit but doesn't yet charge the card.

The transaction lifecycle for this scenario might occur as follows:

1. The cardholder books a hotel online and enters their payment card details.
2. The merchant sends a pre-authorization message to Highnote for $1,000 (even though the room is only $800).
3. Highnote interprets the message as an AuthorizationEvent and places a hold for $1,000 on the cardholder's financial account.

Mid-stay: During their stay, the cardholder expenses a business dinner in the hotel restaurant ($350) and books a spa treatment ($150). The hotel sees that the room ($800), plus the additional charges ($500), went over the initial pre-authorization amount by $300. Rather than creating a separate transaction, the hotel submits an incremental authorization (with the same transaction ID as the pre-authorization) for an additional $500, increasing the total authorized amount to $1,500.

The transaction lifecycle for this scenario might continue as follows:

1. The cardholder charges $500 of additional services during their stay.
2. The merchant sends Highnote a an incremental authorization message for $500 using the same transaction ID.
3. Highnote interprets the message as a second AuthorizationEvent and places an additional hold of $500 on the cardholder's financial account, bringing the total to $1,500.

Check-out: When the cardholder checks out, the final bill totals $1,300. Because the hotel had authorized $1,500 (pre-auth + incremental auth), they have an excess authorization of $200. The hotel processes an authorization reversal of $200 and tells cardholder's bank to release the hold on that extra $200. The reversal uses the same transaction ID, ensuring that all authorization messages are linked and the cardholder only sees one $1,300 charge on their statement.

The transaction lifecycle for this scenario might resolve as follows:

1. At check-out, the hotel submits a capture request to Highnote of $1,300 for the total amount of the stay.
2. Highnote interprets the capture request of $1,300 as one ClearingEvent
3. Highnote reverses the excess hold amount of $200 using a ReversalEvent.

Scenario (blue sweater): A cardholder purchases a cerulean blue sweater, but returns it after the transaction has already cleared.

The transaction lifecycle for this scenario might occur as follows:

1. The cardholder purchases a cerulean blue sweater in a store.
2. The merchant sends a single-message authorization request to Highnote.
3. Highnote interprets the authorization message as an AuthorizationAndClearEvent and approves the transaction, resulting in settled money movement from the account holder’s financial account to the merchant’s bank account.
4. The cardholder returns the sweater.
5. The merchant sends a single-message authorization request to Highnote with the refund amount as a credit.
6. Highnote interprets the authorization message as an AuthorizationAndClearEvent, with the refund amount processed as a credit to the account holder’s financial account.