# Transaction Lifecycle

Understanding the complete transaction lifecycle ensures you implement a robust and reliable payment flow. This page explains the end-to-end journey of a Tap on Phone payment, from checking the initial terminal status to determining the final transaction outcome.

## The Standard Payment Flow

A successful payment transaction generally follows a standard sequence of events between your client application and the Tap on Phone application.

1. **Status Verification (Optional but Recommended):** Before initiating a payment, your application broadcasts a status request. This confirms the Tap on Phone app is in the `Initialized` state. If the status is `None`, you must prompt the merchant to initialize the POS.  
2. **Proactive Attestation (Optional but Recommended):**  
   To prevent unexpected UI delays while the customer is waiting, your application broadcasts an attestation request. This ensures the device's security token is valid *before* launching the payment interface.  
3. **Intent Initiation:**  
   Your application launches the Tap on Phone `POSActivity` using an Android Intent. You pass the transaction details (such as the amount in cents, the transaction type `PURCHASE`, and your SSO credentials).  
4. **Payment Execution:**  
   The Tap on Phone app takes over the screen. It prompts the customer to tap their card or device, securely reads the data, requests a PIN if necessary, and communicates with the backend to authorize the payment.  
5. **Result Callback:**  
   Once the payment finishes, the Tap on Phone app closes and returns an `ActivityResult` to your application.

## Determining the Final Status

When your application receives the Activity Result, you must evaluate specific fields to determine if the payment was successful.

* `RESULT_CANCELED`: The user manually canceled the transaction (e.g., by pressing the back button), or a fatal error occurred before the transaction could go online. No receipt is generated.  
* `RESULT_OK`: The transaction process completed, and a receipt was generated.

<Callout type="warning">

`RESULT_OK` does not mean the payment was approved.** It simply means the process finished without a fatal system error.

</Callout>

To determine if the funds were actually secured, you must inspect the `status` extra returned within the `RESULT_OK` intent:

* If `status` is `APPROVED`, the payment was successful.  
* If `status` is `DECLINED`, the payment was rejected by the issuer or network. You should check the declineCause and declineError fields to understand why.

## Handling Missing Responses

In mobile environments, applications can crash, or the Android operating system might kill your app while it is in the background waiting for the Tap on Phone app to finish.

If your application never receives the transaction intent response, you must not assume the transaction failed. The Tap on Phone app might have successfully processed the payment while your app was disconnected.

### The Recovery Flow

To recover a missing transaction outcome, use the asynchronous status broadcast:

1. **Capture the Transaction ID:** When you initially launch the payment intent, the Tap on Phone app broadcasts a `sdkTransactionId` as soon as the transaction begins. Your application should listen for the `TRANSACTION_BROADCAST_RESPONSE` and temporarily save this UUID.  
2. **Wait:** If your app misses the final result, wait at least 5 to 10 seconds to ensure the backend has completely processed the transaction.  
3. **Query the Status:** Broadcast a `TRANSACTION_STATUS_BROADCAST `containing the saved UUID.  
4. **Process the Result:** The Tap on Phone app responds with either the complete receipt details (allowing you to check if it was `APPROVED` or `DECLINED`) or an error.

If the recovery broadcast returns an error, we recommend retrying it once to rule out temporary network issues. If it fails a second time, you can safely consider the transaction declined or void.