Stripe, PayPal, Manual Payments: Wiring Up Three Gateways in Your Chiptuning Portal

A chiptuning portal that takes one payment method is a portal that loses customers. A workshop in the UK that only accepts Stripe loses the customer who only uses PayPal. A workshop in Mexico that only accepts PayPal loses the customer paying via Mercado Pago. A workshop with a sub-dealer in India loses the customer expecting Razorpay UPI.

This post walks through the three payment methods that cover 90%+ of chiptuning customers globally — Stripe (cards, Apple Pay, Google Pay), PayPal, and manual bank transfer — what to configure for each, how the webhook side actually works, and which gateways to enable when.

What “enable a gateway” actually means

A payment gateway integration has three pieces:

1. Credentials in your portal settings — API keys, webhook signing secret, optional sandbox keys for testing
2. Webhook endpoint the gateway calls when a payment status changes
3. Display logic in your checkout — the customer sees the gateway as an option only if it’s enabled and applicable to their region/currency

Skip any one of those three and you’ll have a half-broken integration. Stripe configured without webhooks means your portal never learns when a payment succeeded (it’ll work in tests but fail in production). PayPal configured without a webhook signing secret means your portal can’t verify the IPN message and you risk false-positive payment confirmations.

Stripe — set this one up first

Stripe is the dominant gateway for European + UK + LATAM workshops in 2026. Setup:

1. Create the API keys. In your Stripe dashboard → Developers → API keys, copy the publishable key and the secret key. Restricted keys are safer than the master key if you can plan the scopes (charges + customers + webhooks).

2. Configure the webhook endpoint. In Stripe dashboard → Developers → Webhooks → Add endpoint:
– URL: https://your-portal.com/stripe/webhook (your portal exposes this)
– Events to listen for: payment_intent.succeeded, payment_intent.payment_failed, charge.refunded
– Copy the signing secret (whsec_...)

3. Paste the three values (publishable key, secret key, webhook signing secret) into your portal’s Stripe gateway settings. The portal should encrypt these at rest.

4. Test in Stripe’s test mode before flipping to live. Use Stripe’s test card 4242 4242 4242 4242 with any future expiry and any CVC. A successful test transaction proves all three pieces are wired correctly.

5. Enable the methods you want exposed. Stripe supports cards, Apple Pay, Google Pay, SEPA, Bancontact, iDEAL, Klarna, Afterpay, and others. The portal’s checkout shows the methods that match the customer’s locale automatically.

Verification: a real card payment of £1 (refunded immediately) confirms webhook delivery. If your portal doesn’t show the £1 as “paid” within 30 seconds of the customer’s checkout, the webhook isn’t reaching you — check the Stripe webhook log for the failed delivery.

PayPal — second gateway, more friction

PayPal coverage matters in markets where customers don’t trust giving card details to small workshops (older customers, casual buyers, some EU regions). Setup is more involved than Stripe:

1. Create a PayPal business account (separate from a personal account).

2. Create a REST API app in the PayPal developer dashboard. Copy the client ID and secret.

3. Configure the webhook endpoint at https://your-portal.com/paypal/webhook. Subscribe to events: PAYMENT.CAPTURE.COMPLETED, PAYMENT.CAPTURE.REFUNDED, PAYMENT.CAPTURE.DENIED.

4. Decide on sandbox or live. PayPal has separate sandbox + live API roots. Most portals expose a “test mode” toggle.

5. Paste credentials into your portal’s PayPal gateway settings.

6. Test with PayPal’s sandbox accounts — they give you fake buyer + fake seller credentials. A sandbox transaction should flip the request to “paid” in your portal.

Caveats:
– PayPal’s chargeback rate is structurally higher than Stripe’s. Build a refund flow that handles this gracefully (your portal should support partial refunds).
– PayPal’s transaction fees are higher (typically 3.49% + £0.50 vs Stripe’s 1.5%-2.5%). Adjust your pricing accordingly.
– Cross-border PayPal payments include currency-conversion fees PayPal takes from BOTH ends — you and the customer.

Manual bank transfer — slow but margin-rich

Some customers prefer (or insist on) bank transfer — especially for larger jobs (£500+), wholesale orders, or business-to-business. Manual transfer setup is the simplest of the three but requires operator discipline.

1. Add a “Manual bank transfer” gateway to your portal’s settings.

2. Configure the bank details that show up at checkout:
– Bank name + sort code + account number (or IBAN + BIC for international)
– A unique payment reference per order (the portal generates this — the order ID is fine)
– A clear instruction: “Use reference XXXX or your order will not be matched”

3. The order sits in “Pending payment” status until you manually mark it paid.

4. Match incoming bank payments to orders daily (or hourly during busy periods). When you see the customer’s payment in your bank feed, click “mark as paid” in the order → portal flips status, customer gets notified, tuning begins.

Operational rules:
– Set a minimum order value for manual transfer (e.g. £100+) — small orders aren’t worth the matching overhead
– Don’t deliver files before payment is confirmed in your bank — even if the customer sends you a screenshot of “payment sent”
– Set an expiry on unpaid manual orders (e.g. 7 days) — auto-cancel after that, requeue the credit

For wholesale customers (sub-dealers), manual transfer can be the default — they top up a wallet once a month, and credits deduct automatically per file thereafter.

VAT — every gateway needs this right

EU + UK chiptuning workshops must charge VAT on tuned files. Three setups depending on customer location:

The portal should:
– Detect the customer’s billing country from their address
– For B2B, validate the VAT number against VIES (EU’s verification service)
– Show the correct VAT line on the invoice
– Aggregate VAT collected per country into a quarterly OSS / UK MTD return

This logic lives in the portal, not in the gateway. Stripe / PayPal will charge whatever amount you tell them — you’re responsible for calculating the VAT correctly.

Refunds — the cleanest flow

Refunds happen. A delivered file that doesn’t work on the customer’s car; a duplicate order; a chargeback dispute. The portal should expose a refund button per order that:

1. Calls the gateway’s refund API (Stripe charges.refund, PayPal payments-captures-refund, or marks manual as refunded)
2. Updates the order status to “refunded” (or “partially refunded” if amount < total)
3. Reverses any credits / wallet deductions tied to the order
4. Emails the customer the refund confirmation
5. Records the refund in your VAT return so you reclaim the VAT you previously paid

Manual gateways need manual refund — you process the bank refund yourself, then mark the portal order as refunded.

Which gateways to enable when

A starter workshop in the UK: Stripe only. Cover 80% of customers, defer PayPal complexity until you have volume.

A workshop scaling beyond £20k/month: Stripe + PayPal + Manual transfer. Cover the next 15% (PayPal-only customers + the bank-transfer-preferring B2B segment).

A workshop with sub-dealers in non-EU markets: add the regional gateway (Mercado Pago for LATAM, Razorpay for India, Paystack for Africa). Each one mirrors the Stripe setup pattern.

A workshop doing motorsport / dyno-day work: Stripe + Manual transfer. The dyno-day customer is paying in person; the portal records the payment after the fact.

Common failure modes (and how to catch them early)

A health-check page on your portal (we’d put it at /health/payments) should test each gateway weekly with a £0.01 transaction (immediately refunded). If any test fails, you find out before a customer does.

What this looks like in TunerSuite

TunerSuite ships with four built-in gateways: Stripe, PayPal, Mercado Pago, Razorpay, plus manual bank transfer. Each lives in Settings Hub → Payments with the credential fields + webhook test + balance check. VAT handling is automatic across 25 supported countries with VIES validation built in.

Stripe is the most-deployed across the active install base — UK + Western European workshops typically run Stripe-primary, PayPal-secondary. Latin American workshops typically run Stripe + Mercado Pago. Indian workshops typically run Razorpay-primary.

All four gateways are bundled into the TunerSuite licence — £699 setup + £49.99/month — no per-gateway add-on fee, no platform mark-up on top of what the gateway charges you.

FAQ

Do I need to be a registered business to use Stripe?
Yes for proper operation. Stripe will let you start with a personal account but production transactions require business verification. Get this done before you scale beyond £5k/month.

Can I take crypto payments?
Not via Stripe / PayPal natively. A separate crypto gateway (BTCPay, NowPayments) integrates similarly but adds another webhook + reconciliation flow. Most chiptuning workshops don’t have the demand to justify the complexity yet.

What about chargebacks?
Stripe + PayPal both have chargeback dispute flows. Always respond to chargebacks with the evidence trail: signed file delivery, customer’s IP at submission, terms-of-service acceptance, file checksum proof. Workshops winning >80% of chargebacks tend to keep their gateway accounts in good standing.

Can I auto-deduct credits without a charge?
Yes — for wholesale sub-dealer wallets. Customer tops up wallet via Stripe; subsequent jobs deduct credits from wallet with no per-job gateway transaction. See the credit system guide for the full pattern.

Next step

Set up Stripe first, smoke-test it, take real orders for a month. Add PayPal when you’ve heard “do you take PayPal?” more than five times. Add manual transfer when a B2B customer offers to pay £2,000 by bank transfer — that’s the moment the manual gateway pays for itself.

For the wholesale / sub-dealer side of payments, see the credit system guide. For the operational reliability layer (uptime, retry, support), see the 24/7 SLA overview.