Card, wallet and bank payments on your own website, settled to your own account.
This page explains where a card goes when a shopper pays you, what happens when it is declined, and how the money reaches your bank. Most of it is deliberately unexciting.
What you can accept
Visa, Mastercard, American Express and Discover, in credit and debit forms. Apple Pay and Google Pay, which present the same card through the shopper’s wallet and arrive with the wallet’s own cryptogram. ACH bank payments for shoppers who prefer to pay from a checking account, which matters more for wholesale and for larger orders than it does for a typical cart.
All of them run through one account, land in one ledger and show up on one payout. You do not get a separate contract or a separate statement for wallets or for ACH. Payments are processed through US acquiring banks and payment processors; your business is the merchant for its own sales and is paid out to a bank account in its own name.
Subscriptions, invoices, payment links and the thank-you page upsell all charge the same vaulted card that was used at checkout. They are described on their own pages; this one covers the first payment and what follows from it.
Where the card goes
The card number is typed into the vault, not into your site. Everything else follows from that.
The card number, expiry and security code fields on your checkout are hosted fields: small frames served by the vault provider and placed inside your page. When the shopper types, the digits travel from their browser to the vault, which is certified at PCI DSS Level 1, and the vault hands back a token. Your page, your server and our servers see the token, the last four digits, the brand and the issuing country. None of them ever see the full number.
The practical result for you is a shorter PCI questionnaire. Because card data never passes through code you wrote or hosted, your own obligation stays at SAQ A, the shortest form, and it stays there when you add subscriptions or upsells because those charge the token rather than a stored number. We keep the token for as long as the shopper has a reason to be charged again and delete it when they ask or when the account closes.
If you prefer not to maintain a checkout page at all, the hosted checkout does the same thing on a page we serve under your name and your domain. The WooCommerce and Shopify plugins and the API use the same hosted fields, so moving between them later does not change where the card goes.
What the shopper sees
Most disputes begin with a shopper who does not recognize a charge. The checkout is arranged to prevent that.
The statement descriptor for your account, the short text the shopper will later see on their card statement, is printed on the checkout page next to the pay button and again on the confirmation page and in the confirmation email. For your account it is the descriptor set for your account. It stays the same on every charge, including renewals and upsells, so a shopper looking at a statement three weeks later can match the line to the purchase.
The billing address is collected on its own, separately from the shipping address, and sent with the authorization so the issuing bank can compare it to the address on file. A shipping address that differs from the billing address is normal for gifts and for people who ship to work; a billing address that does not match the card is a different thing, and keeping the two fields apart is what lets the check mean something. The security code is always requested on a first payment.
Your refund and cancellation terms are shown beside the pay button, in full, not behind a link, and the shopper confirms them with a checkbox that is never ticked in advance. The time, the wording and the page are recorded with the order. If a dispute arrives later, that record is part of the response.
What happens on a decline
When the issuing bank declines a card, the shopper is told why in words they can act on: the card has expired, the bank wants them to confirm the purchase, there are not enough funds, the number was typed wrong. We translate the issuer’s code rather than showing it. The order is held as pending for thirty minutes so the shopper can try again, fix a digit or use another card without rebuilding the cart, and no “failed order” email goes out during that window.
We do not retry a declined card on our own; the shopper decides whether to try again. A second click on the pay button during a slow authorization is refused without charging, so a nervous shopper cannot be billed twice.
In the dashboard, each unpaid order shows the decline reason in the same plain words and a payment link you can send by text or email. The link opens the same cart with the same terms, expires when you say, and the resulting payment is recorded against the original order so your reporting is not split in two.
Settlement and payouts
The money goes to one place, on a schedule you choose, with every order listed.
Card sales usually settle on the next business day and are paid out daily or weekly, whichever you chose at setup. Each payout is a single transfer to the bank account verified during review, and the dashboard shows what is inside it: the orders, the refunds and disputes netted against them, and each fee line. The monthly statement repeats the same figures to the cent, so the dashboard, the payout and the statement never disagree with one another.
Processing fees are deducted from each payout. The platform fee is billed monthly in advance on its own line. Every fee is stated in your agreement before you sign; none is added after onboarding without notice. If a reserve applies to your account, which is decided in review and not afterwards, the percentage and the release period are in the agreement too, and the held amount is shown on every payout until it is released.
- Schedule
- Daily or weekly, chosen when the account is set up and changeable from the dashboard with one business day’s notice.
- Destination
- A bank account in the business’s own name, verified during review. Payouts are never split to a second account.
- Contents
- Every payout lists the orders it contains, the refunds and disputes netted against them, and each fee line, so the amount that lands can be traced order by order.
- Timing
- Card sales settle on the next business day in most cases. ACH takes longer because the shopper’s bank has a return window; the payout shows which orders are still inside it.
- Statement
- A monthly statement with the same figures as the dashboard, itemized to the order, for your bookkeeper.
Refunds and card updates
Refunds are issued from the dashboard or by API, in full or in part, back to the card that paid. There is no fee for a refund. The transaction fee on the original charge is not returned, because the card networks do not return it to us. The refund appears under the same descriptor as the purchase and is netted against the payout it falls in, which the payout detail shows line by line.
When a shopper’s bank replaces their card, the token usually keeps working because it is tied to the card account rather than to the printed digits, and the networks pass expiry and number changes along. When an update does not arrive in time, the next charge fails, you see it as a decline with the reason, and the shopper receives a link to enter the new card into the hosted fields. The old token is retired and the new one takes its place on any subscription or saved-card record without you touching it.
Common questions about payments
Does the shopper leave my website to pay?
No. The checkout page is on your domain and carries your name and your products. The three card fields are small frames served by the vault provider, placed inside your page, so the shopper types the card number into the vault rather than into your site. Everything around those fields is yours. If you use the hosted checkout instead of your own page, it still runs under your name and your descriptor.
What happens to a saved card when the bank issues a new one?
The token in the vault is linked to the card, not to the sixteen digits printed on it. When an issuer replaces a card for expiry or loss, the networks pass the update along and the token keeps working in most cases. When it does not, the next charge against it fails, you see the decline reason in the dashboard, and the shopper gets a link to enter the new card. We do not store the new number anywhere outside the vault.
Can I refund part of an order?
Yes, from the dashboard or by API, in any amount up to the original charge, as many times as you need until the charge is fully refunded. There is no fee on a refund. The transaction fee on the original charge is not returned, which is how the card networks treat it, and the refund shows on the shopper’s statement under the same descriptor as the purchase.
Do you charge a card again if the first attempt is declined?
Not without the shopper. A soft decline is explained to them in plain words, the order is held for thirty minutes, and they can try again or use a different card. We do not retry a card in the background. You can send a payment link afterwards if the shopper wants to finish later.
What do I need from my side to take ACH?
Nothing beyond turning it on. The shopper connects a bank account or enters routing and account numbers in a hosted field; micro-deposit verification is offered when instant verification is not available. ACH payments take a few business days to clear and can be returned by the shopper’s bank inside the return window, so the payout marks them separately until that window closes.
Ready to move your checkout?
Tell us about the store and what it processes today. We will say what review needs before you spend time on documents, and we will look at your current checkout before the call.