Design an online checkout
A practical interface blueprint for an order summary, secure payment collection, and a clear payment outcome.
Show the decision before the payment
The illustration is an original Betterpay UI example. Keep the order, amount, and action together so the customer can review what will happen. Design the mobile version first: an order summary followed by payment collection and a single primary action. checkout
Assign each part of the screen a job
Use this as a design checklist for your own checkout, rather than a required gateway field list. UI region Recommended content Design purpose Order summary Recognizable product or service, reference, total and currency Let the customer verify the purchase. Payment area Supported payment methods and secure collection component Keep collection consistent with the integration. Primary action A clear action such as Pay $120.00 Make the commitment and current amount explicit. Outcome Result, order reference, receipt or next step Explain whether the customer needs to act again.
Connect the visual flow to the integration
NMI recommends Payment Component and REST API for new web integrations. The component captures payment details and returns a token; your server processes that token and returns a payment outcome. An available token is not itself proof of a successful charge. online Load the order and supported methods from your application configuration. Mount the payment component within your design; do not replace secure fields with ordinary card inputs. Validate the order and payable amount on your backend before processing. Present the returned outcome and update the order only when its payment requirements are satisfied.
Design the states before polishing the colors
Recommended copy below describes application states, not named gateway response values. State Example interface copy Required design behavior Ready Pay $120.00 Enable the action only when required input is complete. Processing Checking your payment… Prevent repeat submission while preserving context. Declined This payment was not approved. Try another method. Offer recovery without exposing internal error details. Uncertain We are checking the payment status. Do not encourage another charge until reconciliation. Complete Payment received. Booking confirmed. Show confirmation only after both claims are true.
Review the accessible mobile experience
Use original product acceptance criteria: visible labels, keyboard focus, a readable amount, and status announcements that do not rely on color alone. Test the page at 320px and at enlarged text settings. Check keyboard order through summary, method selection, secure fields, and action. Keep validation next to the relevant field and preserve entered non-sensitive information on errors. Ensure a fixed bottom action does not cover fields or the error explanation. Implement Payment Component Test payment outcomes