What do I need to accept payments on a website?

A payment processor account, a checkout flow that collects the order and the payment, and a way to confirm and record each sale. The processor handles the card network and the bank. Your job is to send a clean order to it and to record what comes back.

Do I need to handle credit card numbers myself?

No, and you should not want to. Modern processors collect card details on their own hosted page or secure fields, so the raw card number never touches your server. That keeps the heaviest security and compliance work with the processor instead of with you.

What is the difference between test mode and live mode?

Test mode lets you run the full checkout with fake card numbers, so no real money moves. Live mode processes real payments from real buyers. You build and verify everything in test mode, then switch to live once the flow works end to end.

How long until money reaches my bank account?

A successful charge is captured almost instantly, but processors hold funds before paying out, often on a rolling schedule of a few business days. New accounts can see a longer initial hold. Check your processor's payout schedule so cash flow is not a surprise.

Guide

How to accept payments on a website

Accepting payments comes down to four things: pick a processor, build a checkout flow, keep card data off your own systems, and test before you go live. None of it is exotic, but the order matters and the security part is not optional.

How online payments actually work

When a buyer pays, several parties act in sequence. Your site collects the order. A payment processor passes the card to the card network. The buyer's bank approves or declines. The money settles, and the processor later pays it out to you.

You do not build any of that. You connect to a processor that has, and you focus on two things: handing it a correct order, and recording the result so you know what was paid, refunded, or still pending.

Choosing a payment processor

The processor is the single most important choice. Stripe, PayPal, and Square are common picks. Compare them on a few real points rather than on brand:

Fees

Most processors charge a percentage plus a fixed amount per transaction. Watch for extra fees on currency conversion, chargebacks, or international cards. For a small store, the per-transaction rate matters more than any monthly plan.

Availability and payout

Confirm the processor supports your country and your bank, and check how fast it pays out. A processor that is not available where you operate is a non-starter, no matter how good it looks.

Payment methods

Cards are the baseline. Wallets like Apple Pay and Google Pay reduce checkout friction and can lift conversion. Check that the processor supports the methods your buyers actually use.

Hosted checkout option

A hosted checkout means the processor handles the payment page for you. It is the fastest, safest path for a small store, because the processor carries most of the security weight. Most major processors offer one.

What a checkout flow needs

A working checkout does more than show a pay button. It needs every piece below, or it breaks somewhere a buyer can see.

A clear order summary. Items, quantities, shipping cost, and tax, shown before the buyer pays. No surprise totals at the last step.
The payment step itself. The processor's hosted page or secure fields, where the buyer enters card details.
A confirmation path. A success page and a way to learn the payment actually went through, usually a webhook from the processor.
A failure path. A declined card should show a clear message and let the buyer try again, not a blank error.
An order record. Every paid order stored on your side, so you can fulfill it, refund it, and send a receipt.

Security basics, kept simple

Card payments come with a security standard known as PCI DSS. The practical takeaway for a small store is short: do not let raw card numbers touch your own server. When the processor collects the card on its hosted page or in secure fields, most of the PCI burden stays with the processor, and your scope shrinks to a much smaller checklist.

Beyond that, serve your whole site over HTTPS, keep your processor keys secret and out of your front-end code, and never store card numbers in your own database. If you find yourself handling raw card data directly, stop and use the processor's hosted flow instead.

Test mode before live mode

Every serious processor gives you a test mode with fake card numbers. Use it to run the full path: add to cart, check out, pay, see the confirmation, and confirm the order was recorded. Try a declined card too, so you know the failure path works.

Only switch to live mode once the test flow works end to end. Then place one small real order yourself and refund it. That final check catches the keys-not-swapped mistakes before a buyer does.

The path commerce.fyi takes for you

commerce.fyi wires real Stripe checkout into your store. You connect your own Stripe account, and the storefront gets a working checkout, with orders, refunds, and receipts handled as real records. There is no payment page to build and no card data on your side.

You still publish the store yourself, which is the step that completes Stripe onboarding and checkout readiness. After that, the checkout takes real payments. The processor is yours, the money is yours, and the order records sit in one place where you can act on them.

You know what you sell. Get the store.

No signup to start. Describe your products and see a real store you can take live.