Checkout
Checkout
Shared across every PremiumPress product. 4 classes in inc/Checkout.
Address Address.php
PPT — the shared shipping-address card used by every checkout that ships physical goods (the Shop cart and the Auction lot payment). Owns the address field set, its sanitising/validation, the destination country list (honouring the admin's restricted ship-to mode), and the live "as you type" shipping-rate preview script — so both forks collect and validate a delivery address exactly the same way. Extracted from the Shop's _sp\Checkout so the two checkouts don't drift. Each fork still owns where the collected address is STORED (its own order-meta keys), so this class deals only in the neutral field array below.
Badges Badges.php
PPT — payment badges. The row of accepted-payment marks ("Payment options") shown to buyers on a listing. The catalogue below is the full set an admin can choose from (Checkout ▸ Badges); the stored selection lives in the ppt_checkout option under the badges section alongside every other cart setting, so it saves through Admin\Checkout::handleSave(). Every mark is a self-contained inline SVG — no external requests, no CDN dependency, crisp at any size, and safe to ship in a client ZIP. They are recognisable brand-styled marks, not the brands' own trademarked artwork. A badge is presentational only: ticking Klarna here does not add a Klarna gateway to checkout. Gateways are configured on the Gateways tab. Emitted in two places, first one wins for a given request (see $done): - the auction lot trust panel (Ppt_at\AuctionLot) - the single-listing sidebar (Directory/templates/single.php, _sp/templates/single-shop.php)
Fulfilment Fulfilment.php
Order fulfilment — where a parcel has got to, and how the buyer follows it. Deliberately a SEPARATE axis from order_status (complete / pending / cancelled), which is about money: an order can be paid and not yet packed, or shipped while the payment is still settling. Mixing the two would make one dropdown answer two questions and force the shop owner to choose which truth to record. Stored per order: order_fulfilment_stage ordered | packed | shipped | delivered order_carrier free text, e.g. "Royal Mail" order_tracking_no the carrier's consignment number order_fulfilment_history stage => unix timestamp, stamped as each stage is reached The history is what turns a dropdown into a timeline: the buyer page dates each completed step from it, so "Shipped 8 Nov" needs no extra data entry. Only meaningful where the theme posts parcels — see enabled(), which keys off ThemeProfiles::supportsShipping() and the Checkout ▸ Shipping switch together.
Shipping Shipping.php
PPT — the single chokepoint that decides a shipping cost, shared by every checkout that ships physical goods (the Shop cart and the Auction lot payment). Everything upstream (_sp\Cart::totals(), _at\Checkout's lot totals, each checkout's AJAX rate preview and server-side recompute) calls quote() rather than reading the admin's shipping settings directly, so the resolution order lives in exactly one place: 1. Shipping disabled → free (amount 0). 2. Restricted-country mode + the destination isn't in the ship-to list → blocked (checkout can't proceed for that country). 3. A live carrier-API provider is enabled (Admin\ShippingProviders, registered by a plugin like ppt-ups/ppt-royalmail via ppt_shipping_rate_quote) → ask it for a real quote; a null/failed response falls through rather than blocking checkout, since a merchant would rather sell at a fallback rate than not at all. 4. A manual per-country rate override (Checkout ▸ Shipping ▸ Countries) → use it. 5. Weight-based rates (Checkout ▸ Shipping ▸ General "Weight-based rates") — no carrier API involved, just an admin-entered "up to this weight → this price" table, the same shape as ppt-royalmail.php's bands but built into the theme so weight-based cost works with zero plugins installed. 6. The global flat rate (today's original fallback) → use it. Whichever of 3-6 produced an amount, the "Free shipping over" threshold then has the final say: once the subtotal clears it, shipping is always free, regardless of which tier calculated the cost. The engine is weight-agnostic: it takes the shipment weight as a plain float, so each fork supplies weight its own way (the Shop sums _sp\Product::weight() per cart line; the Auction reads _at\AuctionLot::weight() for the won lot). Extracted verbatim from the original Ppt\_sp\Shipping so the Shop's behaviour is unchanged — _sp\Shipping now delegates here.