Overview
A single payment in the Juno Portal can generate several events over its lifetime — for example an authorisation followed later by a capture, or a refund. The Portal reconstructs these into one accurate final status using a fixed set of rules, so the same transaction always shows the same status regardless of the order its events arrived in. This article explains what each status means and why a status can briefly differ from what you see in your PMS.
Applies to
| Product | Juno Portal |
| Feature | Transactions — status |
| Audience | All Juno Portal users |
What you'll achieve
You'll know what each transaction status means, why a status might temporarily differ between the Portal and your PMS, and when a status that looks wrong is actually expected.
Before you start
- Open the transaction's lifecycle view if you want to see the individual events behind a status, rather than relying on the status alone.
What each status means
| Completed | The payment was captured. Funds have been taken from the cardholder. |
| Authorised | The card was approved but the payment has not yet been captured. No funds have moved. |
| Partially Refunded | A portion of the captured amount has been returned to the cardholder. |
| Fully Refunded | The full captured amount has been returned to the cardholder. |
| Voided | The authorisation was cancelled before capture. No funds were moved. |
| Unknown | There's not yet enough event data to determine a final state. This typically resolves automatically as further events arrive from the gateway. |
Why a status may differ from your PMS
Gateway events don't always arrive in the order they occurred — a refund event can reach the Portal before the corresponding capture event. The Portal applies fixed precedence rules to work out the correct final state regardless of arrival order: a void always wins over a refund, and a refund wins over a capture. While events are still in transit, statuses may temporarily differ between systems; once every event has arrived, they'll agree.
A transaction still shows Authorised after check-out
If a transaction shows as Authorised after the guest has departed, the capture event may still be in transit from the gateway, or the pre-authorisation hold may not yet have been released. If the status remains Authorised beyond the expected settlement window for your acquirer, contact 934 Support with the transaction ID and date.
Expected result
You can read any transaction's status with confidence, and recognise when a mismatch with your PMS is a normal, temporary timing effect rather than an error.
Need more help?
If a status remains Authorised beyond your acquirer's expected settlement window, or a status otherwise looks wrong after all events should have arrived, contact 934 Support through Help & Support in the Portal or at support@weare934.com with the transaction ID and date.
Comments
0 comments
Article is closed for comments.