What you need before you start building
Building an online payment system means creating the infrastructure that accepts money from customers, holds it temporarily, and moves it to your business bank account. You will need four things in place before you write a single line of code or sign a contract: a business bank account, a payment processor account, a way to store customer data securely, and a decision about which payment methods you want to accept.
The payment processor is the company that actually handles the transaction—they talk to the customer's bank, verify the card or account details, and transfer the money to you. Common processors include Stripe, Square, PayPal, and Authorize.net. Each one charges a fee per transaction (usually 2.2% to 3% plus 30 cents for card payments) and has different rules about what kinds of businesses they will work with.
Before you choose a processor, know what you are selling. Some processors will not work with high-risk businesses like gambling, cryptocurrency, or adult services. If you are selling physical goods, digital downloads, subscriptions, or services, most major processors will take you. If you are unsure whether your business fits, contact the processor's sales team directly—they will tell you yes or no before you build anything.
Key Takeaways
- You need a business bank account, a payment processor account, secure data storage, and a decision about which payment methods to accept before you start building.
- Payment processors charge 2.2% to 3% plus 30 cents per card transaction, and some will not work with certain types of businesses.
- You can use a hosted solution like Shopify or WooCommerce if you do not want to build from scratch, or integrate an API from Stripe or PayPal if you need custom code.
- Customer payment data must be encrypted in transit and at rest, and you must comply with PCI DSS (Payment Card Industry Data Security Standard) or use a processor that handles compliance for you.
- Test your payment flow with test cards and fake transactions before you go live, and monitor for fraud patterns from day one.
Hosted payment platforms versus custom integration
You have two paths: use a hosted platform that handles most of the work for you, or build a custom system using an API. A hosted platform like Shopify, WooCommerce, or Square Online gives you a dashboard, payment processing, inventory management, and a storefront all in one. You do not write code; you configure settings and upload products. The trade-off is that you pay a monthly fee (usually $30 to $300 depending on features) and you are locked into their system.
A custom integration means you build your own website or app and plug in a payment processor's API. Stripe and PayPal both offer APIs that let you accept payments on your own domain. This route costs less per transaction but requires a developer and takes longer to build. You also take on more responsibility for security and compliance. Choose hosted if you want to launch fast and do not need custom features. Choose custom if you need specific functionality, want to own your customer data completely, or plan to scale to high transaction volumes.
How to integrate a payment processor API
If you go the custom route, here is the actual flow. Your customer enters their card details on your website. Your code sends that data to the payment processor's API (never to your own server—that is the critical rule). The processor returns a token, which is a reference to the card that is safe to store. You store the token in your database, not the card number itself. When you need to charge the customer again, you send the token to the processor, not the card number.
Stripe's API is the most common choice for custom builds. You create an account, get an API key, and use their libraries (available in Python, JavaScript, Ruby, PHP, and others) to handle the payment flow. Their documentation walks through the steps: create a payment intent, collect the card details using their hosted form (Stripe Elements), confirm the payment, and handle the response. PayPal's API works similarly but uses a different flow—you redirect the customer to PayPal, they approve the payment there, and PayPal sends you a confirmation.
Both processors handle the hard part: talking to the customer's bank, checking for fraud, and managing chargebacks. You handle the easy part: sending the right data to the API and storing the result in your database so you know who paid and who did not.
Security and compliance requirements
You must never store a customer's full card number on your server. This is not optional—it is the law under PCI DSS (Payment Card Industry Data Security Standard). If you store card data and get hacked, you are liable for the breach, the fines, and the lawsuits. The way to avoid this is to use a payment processor's hosted form or tokenization system, which means the card data never touches your server.
All data in transit must be encrypted using HTTPS (the lock icon in the browser). All data at rest—anything stored in your database—must be encrypted using a strong cipher. Your database itself should be behind a firewall, accessible only from your application server. You should also use a Web Application Firewall (WAF) to block common attacks like SQL injection and cross-site scripting.
If you use a hosted platform like Shopify or a processor's hosted payment form, they handle most of this for you. If you build custom code, you are responsible for it. Many developers hire a security firm to audit their payment code before launch. This costs $2,000 to $10,000 but catches mistakes that could cost far more later.
Testing your payment system before launch
Every payment processor provides test cards and a sandbox environment. Use them. Stripe's test card is 4242 4242 4242 4242 with any future expiration date and any three-digit CVC. PayPal has a sandbox with fake buyer and seller accounts. Process fake transactions, test what happens when a card is declined, test refunds, test what the customer sees at each step, and test what your database records.
Create a checklist: Does the payment go through? Does the customer get a confirmation email? Does your database record the transaction? Can you refund it? What happens if the customer closes the browser mid-payment? What happens if the network drops? What does the customer see if something goes wrong? Test all of these before you accept real money.
After you go live, monitor your transactions daily for the first week. Look for duplicate charges, unusual patterns, or failed transactions that should have succeeded. Set up alerts in your processor's dashboard so you know immediately if something breaks.
Handling different payment methods
Most customers expect to pay with a credit or debit card, but you can also accept bank transfers (ACH in the US), digital wallets (Apple Pay, Google Pay), and buy-now-pay-later services (Affirm, Klarna). Each method has a different flow and different fees.
Credit and debit cards are the standard. Fees are 2.2% to 2.9% plus 30 cents per transaction. Processing takes one to three business days. Digital wallets like Apple Pay and Google Pay use the same card data behind the scenes but are faster for the customer—they just tap or scan. ACH transfers (direct bank-to-bank) have lower fees (0.8% to 1.5%) but take three to five business days and are mainly used for large transactions or subscriptions. Buy-now-pay-later services let customers split a purchase into four or more payments; the service pays you upfront and collects from the customer later.
Start with cards and digital wallets. Add ACH and buy-now-pay-later later if your customers ask for them. Most processors let you enable new methods in your dashboard without rebuilding your code.
Managing refunds, disputes, and chargebacks
A refund is when you give the customer's money back. You control this—you can refund a transaction through your processor's dashboard or API. Most processors refund to the original card within one to three business days. A dispute is when the customer tells their bank the transaction was unauthorized or the product never arrived. The bank investigates and either sides with you or the customer. A chargeback is when the bank forces a refund without asking you first, usually because the dispute was decided against you.
Chargebacks cost you money. You lose the transaction amount plus a chargeback fee (usually $15 to $100). You can contest a chargeback by providing evidence—a shipping receipt, a delivery confirmation, an email from the customer saying they received the product—but the process takes weeks and you might lose anyway. The best defense is to prevent chargebacks: ship physical goods with tracking, deliver digital goods immediately, keep customer communication records, and make your refund policy clear.
Your processor will show you disputes and chargebacks in their dashboard. Respond quickly with evidence. If you get too many chargebacks (the threshold varies by processor but is usually more than 1% of transactions), your processor can suspend your account.
Choosing between monthly fees and per-transaction fees
Payment processors charge in different ways. Some charge a percentage plus a flat fee per transaction (Stripe: 2.2% + 30 cents). Some charge a flat monthly fee plus a lower percentage (Square: $0 to $300 per month depending on plan, then 1.5% to 2.6% per transaction). Some charge a monthly fee with no per-transaction fee if you stay under a volume threshold.
If you process less than $1,000 per month, a per-transaction model is cheaper. If you process $5,000 or more per month, a monthly fee model might be cheaper. Calculate your expected volume and compare. Most processors have a pricing calculator on their website. Also ask about setup fees (some charge $0, some charge $100 to $500), monthly minimums, and whether they charge for refunds or disputes.
Frequently Asked Questions
Can I accept payments without a business bank account?
No. Processors require a business bank account to deposit funds. If you do not have one, open it before you sign up with a processor. Some processors will not deposit to a personal account even if you are a sole proprietor, so check their requirements first.
What happens if a customer's payment fails?
Your processor returns an error code telling you why—insufficient funds, card expired, fraud check failed, or something else. You should show the customer a clear message and let them try a different card or payment method. Do not charge them again automatically unless they explicitly consent to retry.
Do I need to store customer payment data?
No. Use your processor's tokenization system to store a reference to the payment method instead of the actual card or bank account details. This keeps you out of PCI compliance and protects your customers. You can still charge them again using the token if they consent.
How long does it take for money to reach my bank account?
Most processors deposit funds within one to three business days. Some offer next-day or same-day deposits for a higher fee. Check your processor's settlement schedule in their dashboard—it usually shows the exact date money will arrive.
What should I do if I get a chargeback?
Log into your processor's dashboard, find the chargeback, and upload evidence that the transaction was legitimate—a shipping receipt, delivery confirmation, customer email, or invoice. Submit your response before the deadline (usually 7 to 10 days). The bank will review your evidence and decide whether to uphold or reverse the chargeback.