How to Add Payments to Your Website: Bit, Cards, and PayPal on WordPress, Shopify, and Custom Code (2026)

Payments, not magic

"Add Bit and cards" sounds like one line. In practice it is flow, security, and a webhook that updates the order.

Clients often say: "The site is ready, we just need payments." Sometimes that is a Shopify toggle. Sometimes it is a week of redirect URLs, webhooks, sandbox tests, and handling the case where the user closed the browser before the server got confirmation.

This guide is meant to actually help - whether you build yourself, have a developer, or just want to understand what happens behind "Pay now." I am Naor; I have shipped stores and payment flows with PayPal, Stripe, local acquiring, Bit, KashCash, and invoicing. If system wiring feels fuzzy, there is a separate post on APIs and webhooks. Here the focus is money entering your site.

1) Redirect - customer leaves to the provider

Most common and safest to start. Click pay, go to PayPal / Stripe Checkout / acquirer page / Bit, pay, return. Card data does not hit your server. Downside: you must handle return + webhook, not only a thank-you page.

2) Embedded / hosted fields - your page, their inputs

Looks like your site; card fields load from Stripe Elements, PayPal, or an acquirer iframe. Still do not store raw card numbers in your DB. Needs correct JS and CSP that does not block scripts.

3) Direct API (rare for small business)

Your server sends card data to the provider. That brings PCI DSS and serious responsibility. If someone proposes "we will save the card in our table" - pause and ask hard questions.

• Webhook / IPN: provider POSTs to your server when payment succeeds or fails. Source of truth, not the thank-you page.
• Return URL: user lands on success page. Good UX, but they can close the tab before webhook arrives.
• Sandbox / test mode: always test there before live.
• Idempotency: same webhook twice must not create two orders.
• HTTPS: required. Providers will refuse otherwise (correctly).

Before plugins and API keys, ask: where is your site today? That saves weeks of wrong direction.

Scenario A - Shopify / WooCommerce store already live

Products, cart, checkout shell exist. You only need money in. Usually: enable in admin + acquirer/Bit plugin + test order. Do not rebuild checkout from scratch. Focus on provider choice (fees, currency, support) and webhook URL if the plugin needs it.

Scenario B - brochure site / WordPress without a store

One-off payments: consulting, course signup, deposit. PayPal Smart Buttons or Stripe Payment Links work without WooCommerce. If you will sell dozens of SKUs later, move to WooCommerce or Shopify before debt piles up.

Scenario C - custom app (PHP, Laravel, Next.js)

Your business logic: subscriptions, complex orders, CRM hooks. Redirect + webhook is standard. Plan upfront: order table with statuses, webhook endpoint, idempotency, logs. Invoicing and local wallets (Bit, KashCash) belong in one flow, not disconnected buttons.

1. Settings → Payments - enable Shopify Payments (if available in your region) or external provider.
2. PayPal - often one-click setup.
3. Local methods (Bit, etc.) - usually via App Store; check fees and support.

You skip building cart and basic emails. You still own policy: refunds, currency, inventory.

1. WooCommerce → Settings → Payments
2. Local acquirer / Bit plugins - use official or well-maintained plugins.
3. Run a test order; confirm status moves pending → paid.

WordPress without WooCommerce? PayPal Smart Buttons or Stripe Checkout with a light plugin can work for one-off payments. For a real catalog, WooCommerce (or another platform) saves pain later.

1. Create order as pending.
2. Create payment session at provider.
3. Redirect customer.
4. Webhook verifies signature, marks paid, stock down, email out.
5. Return URL shows thanks but is not the only signal.

Always recompute amount on server before creating payment. See also API integration guide.

• Secrets only on server (API routes / server actions).
• Client gets redirect URL or client_secret - never secret keys.
• Webhook endpoint with signature verification.
• Env vars on Vercel - not in git.

Business account, Checkout integration, webhooks for capture events, sandbox tests. Common bug: marking paid on return URL only - use the webhook as source of truth.

Stripe Checkout for international cards. Local acquirers (Israel and elsewhere) often use redirect or iframe with their own API docs. Test mode, merchant IDs in env, webhook callbacks, invoicing if required.

Popular in Israel; still needs business API, credentials, callback handling. Often via WooCommerce/Shopify apps or custom code. Offer alongside cards, not instead of, for many audiences.

Bit does not replace cards for every audience - many businesses offer both and let the customer choose.

• Order status in DB
• Confirmation email
• Invoice if needed
• Stock / digital access only after verified webhook
• Logs with transaction IDs

For what clients should receive when everything is wired (including payment provider access), see the post on what you get at the end of a digital project.

• Trusting return URL only
• Secret keys in frontend
• Skipping sandbox
• Webhooks without signature check
• Client-side amounts without server validation
• Broken mobile redirect flow

1. HTTPS everywhere
2. Test payment including failure paths
3. Webhook logged
4. Idempotent order updates
5. Confirmation email works
6. Refund policy visible
7. Live vs test keys separated

Payments are a secure process: redirect or embed, webhook as truth, then email, invoice, and inventory. Platforms cover a lot; custom code gives control but responsibility.

On WordPress / Shopify - start in the admin, run a test order, verify webhooks. On PHP / React - build sandbox first, secrets on server only, never skip signature verification.