A debit cardholder calls a ride-share service through its app, and the cost of the proposed destination is $25. After arriving at the first destination the cardholder requests a second destination for $15, and then after arriving at the second destination requests a third, for $10. The network is Visa, because the Mastercard simulator does not have incremental authorization capability. The starting balance is $1000.

This example is similar to <a href="page:scenario-3-incremental-authorizations" target="_blank">Scenario 3: Incremental authorizations</a> but with some differences:

• Scenario 3 was derived from live data in Production, where the incremented transactions were authorizations that were later settled. Because of the way the simulator is set up in <<glossary:CV>>, this simulation has preauthorizations for the incremented transactions, which are completed and then later settled.

• The card product in this example has a 15% upcharge for <<glossary:MCC>> 4121 (taxicabs and limousines) that rounds up to the next whole number.

### First preauthorization

Call <a href="ref:post_createsimulatedcardauth" target="_blank">Create Simulated Card Authorization</a> with these parameters:

Capture the `auth_id` for later use.

#### View the preauthorization

Call <a href="ref:post_getauthhistory" target="_blank">Get Authorization History</a> to see the preauthorization. Notice that the `amount` includes the upcharge whereas `local_amt` does not.

### Second preauthorization

Call <a href="ref:post_createsimulatedcardauth" target="_blank">Create Simulated Card Authorization</a> with these parameters:

Capture the `auth_id` for later use.

#### View the preauthorization

Call <a href="ref:post_getauthhistory" target="_blank">Get Authorization History</a> to see the preauthorization. When Galileo received this incremental preauthorization, it backed out the previous preauthorization and replaced it with this one. The `amount` field shows the cumulative amount of the two requests plus upcharges, whereas `local_amt` shows only the amount from this second preauthorization, without upcharges. The `original_auth_id` contains the `auth_id` of the previous preauthorization.

### Third preauthorization

Call <a href="ref:post_createsimulatedcardauth" target="_blank">Create Simulated Card Authorization</a> with these parameters:

Capture the `auth_id` for later use.

#### View the preauthorization

Call <a href="ref:post_getauthhistory" target="_blank">Get Authorization History</a> to see the preauthorization. When Galileo received this second incremental preauthorization, it backed out the previous preauthorization and replaced it with this one. The `amount` field shows the cumulative amount of the three requests plus upcharges, whereas `local_amt` shows only the amount from this third preauthorization without upcharges. The `original_auth_id` contains the `auth_id` of the previous preauthorization.

### Completion

Call <a href="ref:post_createsimulatedcardauth" target="_blank">Create Simulated Card Authorization</a> with these parameters to simulate the completion, because a completion comes to Galileo through the authorization stream. The `amount` is the cumulative amount shown in the third preauthorization.

#### View the completion

Call <a href="ref:post_getauthhistory" target="_blank">Get Authorization History</a> to see the completion. The `amount` and `local_amt` are the same value. In Production, it is possible that the completion would be for less than this amount, for example, if a tip were not included in the total. The `original_auth_id` contains the `auth_id` of the previous preauthorization.

### Settlement

Call <a href="ref:post_createsimulatedcardsettle" target="_blank">Create Simulated Card Settlement</a> with these parameters:

The `settle_dtl` (settlement detail) value can be used for troubleshooting with Galileo.

### Transactions created

Call <a href="ref:post_getalltranshistory" target="_blank">Get All Transaction History</a> to see the ledger entries, in reverse chronological order. For this endpoint response, the `prior_id` contains the `auth_id` of the previous transaction in the sequence.