Custom ecommerce website development
in Philadelphia

Typing a card number is no longer the default way people pay. A checkout built for it alone loses orders it never sees.

Wallets come first, because they remove typing. A shopper with a saved card and an address in their phone can finish in two taps. For most shops that is the largest single checkout improvement available, and it is mostly configuration rather than development.

Instalments are common enough to matter. Whether they suit you depends on basket size and margin, and the decision deserves numbers rather than a feeling. What the build has to handle is the decline: the shopper must land back in a working cart, not on an error page.

Bank transfer shows up in trade selling, where fees on a five-figure order are worth avoiding. It settles slowly, so the shop has to hold the order without pretending it is paid.

Failed payments deserve real work. A declined card on a first order is often a typo or a mismatched postcode, and a clear message recovers it. On a subscription it is usually an expired card, and the fix is a retry schedule plus an email linking straight to a card update form. Shops that do nothing here lose a predictable share of recurring revenue every month.

Fraud screening is a balance, not a switch. Rules that are too tight reject good orders quietly, and nobody reports a sale they did not make. We start permissive, watch what comes through, and tighten with evidence. Manual review needs a queue and somebody whose job it is.

Two practical points. Keep card data out of your systems entirely, through hosted fields or a redirect, so the shop never holds a number. And store the provider's payment reference on the order, because every refund, chargeback and reconciliation question later starts from it.

Reconciliation is the quiet one. Settlement reports, fees, refunds and chargebacks have to match your orders. If nobody built that report, somebody is matching rows by hand at the end of every month.

Currency comes up as soon as the first order arrives from abroad. There are two honest answers and one bad one. Price in your own currency and let the buyer's bank convert. That is simple, and the total is a surprise. Or price per market. That reads better, and somebody has to maintain those prices. The bad answer is a widget that changes the label and charges the original amount anyway. Whichever you choose, fix the currency at the moment of payment and store it on the order. Refunds happen weeks later, at a different rate.

One last item for the build sheet. Decide what happens to a payment method you later switch off. Old subscriptions and saved cards live inside the provider you are leaving. Moving them is a project, not a setting.

Returns are part of selling. A shop that treats them as an exception ends up running them by email.

The shopper's half is short. They should be able to start a return from their account, pick the items and a reason, get a label or an address, and see where the refund is. Every step missing from that list becomes a message somebody has to answer.

Your half is longer, and that is where the money sits.

Reasons matter more than they look. “Too small” and “arrived damaged” lead to different places. One is a size chart problem, the other is packaging or a carrier. Recording the reason in a form you can count turns returns into a product report instead of a cost line.

Exchanges are not refunds. An exchange holds the replacement, ships it, and settles the difference. Run as a refund plus a new order, the shopper pays twice and waits for their money. Run properly, it keeps the sale.

Restocking is a decision, not a default. Some items go straight back on the shelf. Some need inspection. Some cannot be resold at all. The system has to allow all three, and the stock number has to follow.

Refund timing has to be honest on the page. If the money leaves when the warehouse signs for the parcel, say so. Most complaints about refunds are about silence rather than speed.

Then the rules that keep the policy from being farmed: a window, a condition, categories that are final sale, and a flag on accounts that send back most of what they buy. Those are policy questions, and we would rather ask them before the build than find them in the admin later.

Cross-border returns are their own subject. Duties already paid, a label that works in another country, and a decision about whether the item travels back at all or is written off where it sits.

We build the flow around the carrier and warehouse you already use. What we insist on is that both halves exist: the shopper sees status without asking, and you get a report you can act on.