Checkout and Payment in a Store Script

Checkout in a store script is the path from cart to a visible "new order" in the admin panel and, when needed, to online payment. This is where conversion breaks: extra fields, missing delivery, unclear card errors. I test the flow until the manager can see the order without filters or guesswork.

General store flow: store manual. YooKassa is covered separately.

Checkout Steps That Must Be Stable

1. Cart: items, price, quantity, total.
2. Customer contacts with validation.
3. Shipping method and address or pickup point: shipping.
4. Payment method: online, on delivery, or invoice.
5. Confirmation: final total equals products plus shipping minus promo code.
6. Create order in the database, then redirect to payment or the accepted page.

Refreshing step three must not clear the cart. This is a classic session bug across www/non-www domains.

Testing an Order Without Payment

• A product with price and stock above zero goes to the cart.
• Quantity changes recalculate the total.
• The order can be placed with pickup.
• The admin panel shows it immediately as new.
• Order contents and fixed prices match.
• Email may fail, but the order must still exist.

Online Payment Statuses

Minimum matrix:

• pending means waiting for payment;
• paid means webhook confirmed it;
• canceled or failed means unpaid;
• refunded is used if refunds are managed from the cash desk.

The success page after returning from the payment provider is not proof of payment. The source of truth is a signed webhook. Retried webhooks must not create duplicate orders or deduct stock twice.

Promo Codes and Totals

The promo code is applied before payment and the discount is visible in the cart and admin panel. Expired codes produce a clear message, not a 500 error. See promo codes. Do not let users apply a code after a payment has already been created for the old amount.

Stock at Checkout

Between adding to cart and paying, another buyer can purchase the item. Check stock when creating the order and again before payment, or reserve stock for N minutes. For sizes and colors, check the SKU: variants.

Typical UI Holes

• The payment button is active with an empty phone field.
• Courier delivery passes without an address.
• On mobile, the address field is covered by the next button.
• After payment failure the cart is empty.
• Guest and logged-in carts are not merged.

Test in incognito and in a regular logged-in browser.

Connection to Catalog and Ecommerce

Catalog: catalog. Own hosting: ecommerce. Full product: PHP store. Checkout is the neck of the funnel; make the order undeniable in the admin panel.

Form Fields to Remove

Every extra field cuts conversion. Start with phone, name, delivery method, and comment. Company details and tax ids are only needed for B2B invoices. Put data-processing consent behind a link, not a wall of text in the form.

• Normalize phone numbers to one database format.
• Email is required only when receipts or notifications need it.
• Address appears only for delivery methods that need it.

After Clicking Place Order

The user must see an order number and the next step: wait for a call, continue to payment, or use these bank details. The admin panel must receive the order before payment redirect. Log validation, stock, and payment errors separately.

Post-Order Communication

Right after checkout, the buyer worries whether the order arrived. A short accepted screen and later SMS or email reduce support calls. For online payment, show "waiting for payment" until paid. Review the funnel regularly: cart, checkout, paid.

Guest Versus Account

Guest checkout often converts better at launch. Offer account creation after the order. If registration is mandatory, make it a single step with a password or magic link. Move the guest cart into the account carefully and test SKU duplicates.

Before advertising, complete checkout on a phone with delivery and test payment. Amounts in email, admin, and payment provider must match.