PHP MySQL Online Shop Script

A PHP and MySQL online shop script covers the path "product to cart to order" without WooCommerce. It is a separate engine on your hosting: catalog, product page, cart, checkout, order admin. I install it for clients who need their own domain and white label, not a builder subscription with a turnover fee.

The first order check is in the shop manual. Below is what the product must contain and how not to confuse it with a simple catalog.

Minimum scope that makes it a shop

• Categories and product page with price, photos, and stable URL.
• Stock, at least simple: zero stock must not go into an order.
• Cart with total recalculation when quantity changes.
• Checkout: contacts, delivery method, payment method.
• Order record in admin even if mail is not configured yet.

A showcase without a cart is a catalog. Mixing terms in a brief is dangerous: the customer expects payment and receives a gallery.

When not to use WordPress

WordPress plus WooCommerce is convenient because of plugins. It breaks on updates, themes, and cache conflicts. A separate PHP script is easier to roll back as files plus dump. Choose a script if:

1. You need your brand without "powered by" in important places.
2. The catalog is relatively stable, not 50,000 SKUs with omnichannel logistics.
3. You want to control payments and webhooks yourself; see YooKassa.
4. You do not want to pay a SaaS platform a percentage from every order.

Admin panel on day one

1. Create two or three categories with meaningful names.
2. Add one product with photo, price, SKU, and stock above zero.
3. If there are size or color options, create SKUs. Practice: variants.
4. Complete checkout as a test buyer until the order has "new" status.
5. Configure delivery zones and pickup: delivery.
6. Connect payment in test mode, then production keys.

Until step 4 is green, I do not promise advertising or a launch tomorrow. Checkout details: payment.

Order as a system object

An admin order must contain:

• items: product, variant, price at purchase time, quantity;
• total, promo discount, and delivery;
• contacts and address;
• payment status and fulfillment/shipping status;
• status history with who changed what and when.

Showing an old order with the current catalog price is a mistake. Store a line snapshot. Promo codes are covered in a separate guide.

Stock and variants

If you sell shirts, a size grid prevents returns and manual chats. Stock belongs to the variant, not a shared "100 for all sizes". With online payment, either write off stock after the successful webhook or reserve it for a session; choose one model and do not mix both. Otherwise two customers buy the last size M.

Hosting connection

Use the PHP version required by the script, MySQL/MariaDB, SSL, and mail for "order accepted" messages. Backup before updates. On a VDS, use a separate vhost, not a temporary subfolder in someone else's site.

Ecommerce on your own server is described in ecommerce script. If you need only a price list without payment, it is a catalog again, not this product.

Checklist before client handover

• Test order is visible in admin without filters.
• Zero stock cannot be added to cart.
• Promo discount is reflected in the order.
• Delivery method changes the total as expected.
• Online payment in test changes status; cancellation does not mark it paid.
• Product page opens by readable URL on a phone.

A PHP MySQL shop script is not a blog theme. It is a sales flow. Close catalog, cart, and order first; then add payments, delivery, and campaigns. Otherwise the showcase is beautiful while the cash register still lives in a manager's messenger.

Roles around the script

Launch usually has three roles, even if two people cover them:

• content: product pages, photos, prices;
• order manager: statuses, calls, tracking numbers;
• admin: payment keys, backups, users.

The admin password does not belong in a shared chat. After YooKassa setup, explicitly disable test keys. A manager needs orders and products; access to mail templates and cron is unnecessary. Shared admin logins make it impossible to know who erased stock.

What I show during acceptance

1. A product page on a phone.
2. The path to an order with pickup.
3. That order in admin with item composition.
4. Status change and, if ready, test payment.
5. Where the backup is and who makes it.

If acceptance shows only banner animation, the shop is not delivered. A banner can be fixed in an hour; the order flow either exists or not. Access documentation goes to the domain owner: hosting, DNS, admin, payment account, mail. A script without owner access is a delayed problem when contractors change.

Content and showcase speed

A PHP shop fails not only because of broken checkout, but also because of heavy photos and empty menu categories. Before handover, hide empty sections, compress previews, and test a product page over mobile. Payment and return legal pages should be short and clear, not copied from someone else's offer.

The script makes sense when the team is ready to live in admin orders. If sales will stay in messengers forever, wait or honestly use a catalog. When you are ready to close payment and delivery, install the engine, run the first order, and only then start advertising.

Accounting connection

Even a simple PHP shop quickly asks how orders reach accounting, spreadsheets, or warehouse systems. At the start, CSV export and manager discipline are enough. The key is not to keep a parallel "real" price table that drifts away from the site. The script should remain the source of showcase prices and stock until a proper exchange exists.

If integration appears later, keep stable SKUs and do not reuse product IDs. Otherwise integration becomes archaeology. Close the order flow on the site, clean the catalog, configure payment, and only then complicate accounting.