Checkout and Payment

This page follows the source-defined storefront path from a product form to a Magento quote and order, then traces three distinct payment implementations: Monext/Payline CPT, Revolut Checkout, and menzzopayment. The source snapshot is axelites/menzzo@6bf5acf477d65bcfd54182549fc9487e110da007. It establishes code paths, not the deployed theme, current store configuration, provider account state, webhook registration, or successful live transactions. Other payment modules in the repository are outside this guide; their presence alone does not establish enablement.

Journey map

View diagram source

sequenceDiagram
  actor B as Buyer
  participant T as Menzzo theme
  participant Q as Magento quote
  participant C as Mageplaza OSC checkout
  participant O as Magento order/payment
  participant P as Monext/Payline
  participant R as Revolut

  B->>T: Submit product form
  T->>Q: Add product, update quote
  Q-->>B: Cart items and totals
  B->>C: Enter address, shipping and payment
  C->>O: Place order with selected method
  alt Payline CPT
    O->>P: Initialize web payment, store token and redirect URL
    B->>P: Browser redirects to provider
    P-->>O: Browser return or server notification
    O->>P: Retrieve payment details by token and synchronize
  else Revolut Checkout
    O->>O: Initialize pending-payment order
    B->>O: afterPlaceOrder redirects to checkout/start
    O->>R: Create or recover hosted order
    R-->>B: Hosted checkout URL
    R-->>O: Signed webhook, retrieve and reconcile order
    B-->>O: Token-protected return, retrieve and reconcile order
  else menzzopayment
    C->>O: Submit manual method and message fields
    O->>O: Checkout-success observer may invoice/capture pending order
  end

Diagram

The market product form posts to Magento's generated product submit URL. Its catalog widget intercepts submission and sends the form as AJAX; the add-to-cart template supplies the button and can substitute a pre-command reservation form for products that match its view model (form, button and reservation branch). These are theme sources; the active storefront theme is not verified here.

Axelites_Fastcheckout also declares JSON cart actions below the drop route. Add saves through Magento's cart model; update changes a quote item and calls collectTotals(); remove deletes the item. The shared helper reads the checkout-session quote and returns its visible items. The files establish these endpoints and behaviors, but do not establish that the product-form widget calls them (route, add, update, remove, quote helper).

The cart layout declares item totals; the Proceed to Checkout control is rendered by the one-page link template. The market one-step-checkout layout configures Mageplaza's address, billing, payment, coupon, and order-summary UI. Magento's quote remains the shared cart and total source; coupon-specific rules and recovery behavior are covered in Promotions and cart recovery. Follow the later order handoff into ERP and shipping in Order to delivery (cart totals layout, checkout button, OSC payment and summary components).

Payment paths

Monext/Payline CPT

For CPT redirect integration, Monext's payment method initialize() calls its web-payment facade with the order's quote ID and stores the resulting token and redirect URL on payment additional information. The facade reads quote products, payment and addresses, collects totals where needed, calls Payline, and associates the token to the quote. Magento's post-order afterPlaceOrder hook then sends the browser to payline/webpayment/redirecttopaymentgateway; that controller reads the last order from checkout session and redirects to the stored URL (CPT initialization, facade and token, browser redirect, renderer hook).

Two server paths can then reconcile the token. The browser return calls synchronizePaymentWithPaymentGatewayFacade(token, true) and redirects according to the result. The gateway notification calls synchronizeNotificationPaymentWithPaymentGatewayFacade(token) and returns an empty response. Both handlers first short-circuit when the token already resolves to a processing or complete order whose email was sent: return redirects through getRedirect(false), while notification returns an empty response. Otherwise they retrieve payment details from Payline; the sync service checks transactions, applies the provider response through the payment-type handler, and can create an order by token if none is found. The return path can restore the cart after a payment error; the notification path does not use that option (return, notification, synchronization).

An additional Core plugin can replace the CPT redirect URL with a Payline Page URL carrying an encrypted, authenticated session payload when that store-scoped adapter is enabled; if it is disabled or cannot build a URL, it leaves Monext's original redirect URL. The code does not establish which branch is configured (plugin, session payload, plugin registration).

Revolut Checkout

The checkout layout registers axelites_revolut_checkout. After Magento places the order, its renderer redirects to the configured start URL. The method initializes the Magento order as pending_payment, records the amount authorized, and suppresses the initial new-order email. The start controller verifies the checkout-session order, locks by Magento entity ID, and creates or recovers the hosted Revolut order. The request payload uses EUR cents and the Magento increment ID as merchant_order_data.reference; the service stores the external order ID and mode against the Magento payment (layout and renderer, method initialization, start, payload, order recovery, saved payment identifiers).

The browser return resolves the Magento increment ID through a stored return-token hash, retrieves provider state, and redirects to success only after synchronization completes. Transient states show a polling page. A FAILED result restores the checkout failure session; a CONFLICT displays a failure result without that restoration. Separately, the webhook handler verifies the raw-body signature, scopes the lookup by store and mode, matches the external order ID, and invokes the same synchronizer (return, status polling, webhook, order resolver).

The synchronizer retrieves the external order before taking a Magento order lock, then validates method, mode, store, external order ID, amount, currency, and increment ID before changing local state. completed registers a Magento capture. Provider failed or cancelled can cancel a locally cancellable order. A locally cancelled Magento order that Revolut reports as completed becomes a reconciliation conflict with a manual payment/refund review note; it is not silently reopened (validator, state transitions and capture, cancelled-order conflict).

menzzopayment

This is a Magento offline payment method. Its renderer submits boutique_method and boutique_message; the template requires both a selected method and a comment. On REST order-save, an observer copies those values from payment additional data to quote and order payment. A separate checkout-success observer acts only when the order is still pending, uses this method, and can be invoiced: it calls capture and changes state/status to processing. That path contains no remote provider request or callback in the inspected module. The save observer catches Throwable around input resolution and field copying, but its missing-payment guard throws before that catch. The checkout-success observer catches Throwable around its body without recording a recovery status (renderer data and validation, fields, event registration, REST field copy, success handling, offline method).

Identifiers and states

Identifier	Owner	How the path uses it
Quote ID	Magento quote	Cart endpoints use the checkout-session quote; Payline initialization passes the order's quote_id to its web-payment facade.
Magento order entity ID	Magento sales	Revolut start locks and synchronizes using the local entity ID.
Magento increment ID	Magento sales	Revolut sends it as the external merchant reference and uses it to resolve browser returns and webhooks.
Payline token	Monext/Payline mapping	Associates the provider payment with the quote/order; return and notification handlers use it to retrieve provider details.
Revolut order ID / payment ID	Revolut, then Magento payment additional information	The order ID binds callbacks to a local order; a successful payment ID is recorded with the capture transaction when returned.
Revolut return token hash	Magento payment additional information	Authorizes browser return and polling lookups without using the order number alone.
boutique_method / boutique_message	menzzopayment payment data	Carries the chosen manual method and customer text from checkout into quote/order payment data.

Path	Initial local state	Source-backed transition	What success means in this code
Payline CPT	Payline pending status selected during initialize()	Already-processing/complete orders with email sent short-circuit; otherwise return/notification retrieves provider details and delegates to the payment-type handler, with duplicate-transaction checks.	Magento payment/order reflects the provider response handled by Monext. This source does not prove a notification arrived.
Revolut Checkout	pending_payment; order email suppressed	pending, processing, and authorised remain transient; completed registers capture; failed/cancelled can cancel the order.	Magento records the verified provider capture. A cancelled-local/completed-external mismatch is a conflict requiring human payment and refund review.
menzzopayment	Config-dependent; the success observer only handles a pending order	Checkout-success observer calls capture if the order can be invoiced, then sets processing.	The local observer advanced the order; this is not evidence of a remote provider settlement.

Failures, callbacks, and refunds

• Payline return and notification are distinct. Return errors are logged and can restore the cart; the notification endpoint logs caught Exception instances and returns an empty response; other Throwable types are outside that catch. Before retrying a payment, compare the Payline token/provider details with the Magento order payment transactions and status. The sync service contains duplicate-transaction handling, but source does not establish an external delivery or replay policy.
• Revolut return can remain pending. If state retrieval is temporarily unavailable, the customer return can continue polling. Invalid external order data is rejected before mutation. A verified webhook performs the same remote-state reconciliation; the controller's source does not establish that a webhook is registered or delivered. For a cancelled-local/completed-external conflict, reconcile provider payment ID and Magento transactions before any refund action.
• Refund paths differ. Monext CPT declares refund capability and calls Payline's refund facade, subject to the selected contract. The Revolut flow documented here handles capture/cancel reconciliation; its cancelled-order conflict explicitly requires manual refund review. menzzopayment is offline in its method model and this module path does not define an external refund callback. This code evidence does not establish current refund policy or provider account behavior (CPT refund gate, Payline refund call).
• menzzopayment observer errors are quiet. Its input-copy and checkout-success catch blocks suppress Throwable without recording a recovery status; the save observer’s missing-payment guard is outside its catch. If local state does not match the expected checkout result, compare quote/order payment fields, invoice and order status with the relevant owner before replaying.
• Cart JSON is an intermediate result. The custom add/update/remove actions return item details or an error payload; that does not prove checkout submitted or an order exists. Re-read the Magento quote and order boundary before diagnosing payment state.

Enablement and runtime unknowns

The Revolut method's availability check requires the parent method to be available, a store-scoped API key, an EUR quote, and valid renderer configuration when that optional renderer is enabled. The source also has sandbox/live modes and webhook-signature validation. Payline's redirect mode and optional signed page depend on store configuration. menzzopayment has a configurable order-status branch, and its success observer only processes pending orders. Those are source-level gates, not evidence that any branch is active for a current store.

This review did not inspect runtime/admin configuration or credentials and did not test a storefront or payment account. The active theme, enabled payment methods, provider mode, Payline callback registration, Revolut webhook registration, external account credentials, logs, current orders, refund outcomes, and delivery acceptance remain unverified. No background payment reconciliation job is established by the controller paths described here.