Transaction Decision
The TrustFactor transaction decision process allows users to securely decide on transactions. Upon receiving a push notification, the user reviews transaction details and decides on the transaction, all from the TrustFactor app.
Key Steps
- User taps on the push notification on their device, which triggers a request to retrieve transaction details from the TrustFactor API.
- The user reviews the transaction details on their device and makes a decision on the transaction.
- The decision is sent to the TrustFactor API, which validates if the transaction is still decidable.
- Upon validation, a callback is sent to the application notifying it of the transaction decision.
- The application displays a UI showing the transaction's decision. If the transaction was accepted, the original action (e.g., bank transfer) is completed.
Assumptions:
- User already has TF App opened and authenticated
- User is on the "Transaction Details" screen on TF App
After transaction creation the user will receive a push notification on his TF Agent notifying him of the new transaction. After transaction details review (transaction description, parameters, etc) the user is prompted for a decision: Accept or Decline.
Requiring a precise location
When a transaction was created with require_precise_location, the TF App has to collect a position and send it together with the decision.
In order to accept the transaction, the user must consent TF App to access GPS location from his device and send the coordinates on the decision request.
Declining never requires a location. A user can always reject a transaction, whatever the transaction requires.
The position shared with the decision is a fresh fix that the user consented to at that moment. It is not the device's last known location, which TrustFactor keeps from the positions a device shares out of band: that one never expires and may have come from GPS, WiFi triangulation, the carrier or an IP lookup. Both are recorded against the decision and the Backoffice shows them separately, under Location shared with the decision and Last known location before the authentication.
The decision location travels beside the payload the device signs, rather than inside it. It is therefore tamper-evident once TrustFactor has received it - the signature proof covers it - but it is not attested by the device itself.
Confirmation code
When a transaction requires a confirmation code, the TF App shows the shuffled list of options along with the transaction details. The user reads the correct code from the client application's own screen and taps the matching option.
Every other decision-time requirement - PIN, biometrics, a precise location - leaves the transaction pending so the user can try again. A wrong confirmation code does the opposite.
The decision is recorded with the status Failed, the transaction reaches a final state, and the callback to the client application is sent as usual, so the application learns the outcome and can block the original action.
Declining never requires a confirmation code either.