Payment state flow
Never change the provider amount after a payment link is created. Create a new approved request or follow the supported revision behavior when one exists.
Estimate and invoice line amounts and persisted totals support 0 through 999,999,999 minor units (for LKR, up to LKR 9,999,999.99). Manual payments and standalone or invoice-linked payment requests use the stricter positive range of 1 through 99,999,999 minor units (for LKR, up to LKR 999,999.99). If the amount is outside the applicable range, Motornauts rejects the operation before creating or changing a payment record; staff must not split one logical payment to bypass this product limit.
Payment request input accepts ISO-4217 currency codes at the schema boundary, but the selected
payment provider must also support the requested currency. In Phase 2 PayHere-backed payment requests
start with LKR; requests in another currency should be corrected or handled outside the provider
handoff until approved provider and account-plan readiness exists.
If online payments show provider not ready, do not retry the provider handoff until the readiness
owner has cleared tenant credentials, provider setup, Motornauts support review, and the module
dependency readiness gate. Browser return from a provider page is not proof of payment success;
Motornauts shows status from backend state and validated provider callbacks.
PayHere handoffs use a backend-created form post and a provider-specific backend callback. For an invoice payment started from the customer portal, return and cancel navigation opens the exact protected invoice/payment-result page. That page performs a fresh authenticated backend read; the browser return itself is not a receipt or status signal. Legacy invoice flows keep returning to their invoice detail. Staff should wait for callback or reconciliation state before treating a payment as final.
Motornauts does not store card numbers. Customers enter payment details on the PayHere-hosted Checkout surface after Motornauts creates the safe handoff. Motornauts keeps the payment request, provider order reference, status, and sanitized callback/reconciliation evidence needed to show state and support disputes.
Payment-link credentials stay in the customer’s browser tab and are sent to Motornauts in an authorization header. They are not included in PayHere return/cancel fields or API query strings. If the customer opens the clean PayHere return in a different tab or browser, they must reopen the original payment link. The payment page removes the credential from the address bar before loading; do not copy a cleaned return URL and expect it to work in another tab.
Public payment-link access is valid only while the request is pending or processing and before its expiry. Motornauts revokes the capability at expiry or any terminal payment state and removes the tab-scoped copy after a denied load. Customers should use their authenticated portal or contact the service center for a final receipt/status; staff use the protected payment workspace. While the link remains active, Check status performs a fresh backend read. If loading fails temporarily, Try loading again retries only that status read; it does not retry or submit a payment.
On customer invoice pages, choose Pay online to prepare the current payable request, then explicitly choose Continue to secure payment for the provider handoff. Motornauts never auto-submits checkout. The protected result keeps invoice settlement and the online request outcome separate: a cash or bank payment may change the invoice balance without proving PayHere success, and an online success record does not fabricate a zero invoice balance. Reconciliation always shows as under review. Provider order IDs, transactions, callback evidence, credential versions, and raw checkout fields are not part of the customer result.
An invoice can have only one pending or processing PayHere request for its full balance. If another staff or customer action already created that request, Motornauts keeps the existing link and asks the later caller to use it instead of issuing a second provider order. Wait for the request to reach a safe terminal state before creating a replacement.
Saving changed PayHere credentials creates a new credential version and resets provider readiness for that version. Older encrypted versions remain callback-only for requests that were already issued; they cannot be selected for new checkout handoffs. A callback replay is recorded as sanitized evidence but does not apply the payment or invoice side effects again.