HardwareHQ
Prices and builds

Service policy

Payment Options

How money moves on this store, which rails are switched on today, and what an order actually keeps.

What checkout offers right now

The methods offered at checkout are the ones whose credentials exist on this deployment. The list is derived from configuration rather than written into this page, so a rail is never advertised here before it can actually take money.

This page names no rail in its own text. Whatever is available to you is printed below, read from the configuration this deployment holds, alongside a plain statement when nothing is switched on. Where a catalogue is labelled as sample data, no order can be completed on any rail.

Card payments stay with the provider

Card details are entered on the payment provider’s own hosted page. This site builds a signed handoff carrying the order number and the amount in integer cents, then waits for the provider’s server-to-server notification before treating an order as paid.

Nothing card-shaped is stored here: no card number, expiry or security code appears in any table. What is kept is an order row carrying your email, the amounts in integer cents and a status, part lines frozen at their ordered prices, timestamped status events, and the payment attempt - including the raw notification sent by the provider, stored exactly as it arrived, so a dispute can be reconciled against the message rather than against our summary of it.

Bank deposit, when it is switched on

Deposit instructions are printed only when complete bank details are configured and validated — bank name, account holder, an account number of six to ten digits and a six-digit branch code. An incomplete or malformed set makes the method unavailable rather than printing banking details that could send money somewhere unrecoverable.

A deposit needs the order number as its payment reference. No signal arrives from a bank on its own, so somebody has to match the deposit against the statement and write it onto the order; until that happens the order stays unpaid instead of being quietly credited.

If a payment fails or a notification is late

An order moves to paid only when the provider notification matches the stored order number, amount and currency. Notifications are recorded once per provider notification id, so a replay cannot credit the same order twice.

A notification that fails verification is logged as rejected rather than treated as paid, and a transaction status we do not recognise is stored for review instead of guessed at.

What an order keeps about you

What is retained on an order today: your email, the part lines with the titles, SKUs and unit prices captured at the moment of ordering, the goods total, delivery amount and grand total in integer cents, each status change with its timestamp, and the payment attempts with the raw provider notifications they matched. The street address and metro you type at checkout are used there and then - the metro prices delivery, the name and street line travel into the handoff to the payment provider - and no column exists yet to hold them on the order. Email is used for confirmations, and for price-drop alerts only where you asked for them.

Prices shown on this store include VAT, and the figure handed to a payment provider is the same integer-cent total shown in your basket.

Rails switched on for this deployment

No payment rail is switched on here: none of the methods this codebase supports has credentials configured on this deployment, so checkout shows what an order would cost without offering a way to pay it. That is a statement about this deployment, not about the store.