Payment integration for websites

Connect payment to the action you sell.

Add a one-off payment, booking deposit, invoice balance or subscription to an existing or new website. A contained payment integration is usually £300 - £500, with the provider, confirmation and failure route agreed before build.

Try the payment flowChoose an integration level

You own the provider account and receive the funds. Provider transaction, currency, dispute and payout fees remain separate.

Secure provider checkoutexample only
Booking deposit£25.00Consultation, Thursday at 14:00
Verified statusPayment succeededBooking confirmed
CustomerProviderBusiness record

One payment, one provider reference, one business outcome.

Yoursprovider account and payouts
No rawcard numbers stored by the site
Verifiedpayment status before fulfilment
Testedsuccess, failure and refund routes

No card and no signup

The customer sees a payment. You see what it changed.

Choose a purpose, then approve the pretend payment or show the failure route. Nothing is charged, sent or stored. The important part is the verified outcome attached to the correct business record.

Interactive example
01
Customer viewPayment summary
Booking deposit

Consultation, Thursday at 14:00

£50 remains due at the appointment

Payment todayOne payment now£25.00
Card details stay with the payment providerAuthentication appears here when the provider requires it
Deposit terms shown before paymentReady for secure checkout

This demo contains no payment fields and cannot take money.

02
Business viewVerified outcome
planning

No paid record yet

A real integration waits for the provider result before it confirms a booking, invoice, order or membership.

What a payment button leaves unanswered

Money moved. Did the work move too?

A payment button is only the visible step. The business still needs the correct amount, purpose, provider reference, confirmation, refund route and a safe answer when authentication fails or the customer closes the page.

Wrong amount

The payment has no context

Amount, customer and purpose must point back to one booking, invoice, order or account.

False success

A return page confirms too early

The business action waits for a verified provider status, even if the customer closes the browser.

Poor recovery

Failure becomes a dead end

A clear retry route protects the sale without creating duplicate records or charges.

After payment

Refunds drift from the record

The customer message, provider action and business status need one agreed owner.

The status is the instruction

Never fulfil from a thank-you screen alone.

The website creates one payment for one agreed business action. The provider handles secure card entry and any required authentication. A verified server-side status then updates the booking, invoice, order or membership and sends the right confirmation.

The provider handles card entry. The website handles what the verified result means for your business.

01
CreatedAmount and purpose locked
awaiting customer
02
AuthorisingProvider handles the payment step
not fulfilled
03
VerifiedBusiness action may complete
confirm and notify
04
Changed laterRefund, dispute or renewal updates
record follows status

One payment principle, different purposes

Charge the right amount. Trigger the right next step.

Subscriptions and memberships

Recurring amount, frequency, failed renewal, cancellation and access rules are agreed together.

Explore connected systems

Choose the smallest dependable route

Link, embed or integrate.

Best for an owner who needs to add a contained payment to an existing website, booking route, invoice or form. A hosted payment link is enough for a simple manual process, embedded checkout keeps a smoother branded route, and a custom integration is appropriate when payment must update other records automatically.

01A simple manual process is enough

Hosted payment link

The provider hosts checkout. Staff reconcile the payment with the customer or reference using an agreed process.

Fastest when no other record must update instantly.
02Payment belongs inside one clear journey

Embedded checkout

The provider handles card entry while the website controls the amount, purpose and next step.

Best for a contained form, booking or balance.
03Several records depend on payment

Custom integration

Verified events update bookings, invoices, memberships, CRM records or permissions automatically.

Best when payment is one state in a larger system.

Provider checked before the quote

Stripe, PayPal, Worldpay or another supported provider.

Ernest checks the real account, documented payment methods, currencies, recurring behaviour, refunds and verified event route. The proposal names the provider and exact connection.

Website, booking or invoiceEmail confirmation and receiptVerified payment statusProvider account and payoutsCRM, accounts or membership record

Test and live credentials kept separate

Provider event signatures and duplicate delivery handled

Manual support and reconciliation route documented

Proof is the awkward path

Test beyond the successful card.

A sandbox success is only the beginning. Acceptance testing covers browser exits, authentication, delayed events, retries, refunds and staff recovery against the real business action.

See broader ecommerce development
01The customer closes the tabThe server still receives the final status.
02Authentication is requiredThe action waits until payment completes.
03One event arrives twiceIt does not create two business records.
04Payment fails or stays pendingNothing is falsely confirmed.
05A partial refund is issuedAmount and status remain traceable.
06A renewal cannot be collectedCustomer and access follow agreed rules.

Payment integration price

Price the transaction, status and next step.

The range covers one contained payment route on an accessible website. Provider choice, business action, confirmation, failure and refund behaviour are named before work starts.

See all website and system prices
Typical one-off integration£300 - £500usually 2 to 5 working days
  • One provider and one contained payment purpose
  • Secure checkout or provider component
  • Verified status and customer confirmation
  • Success, failure and refund-route testing

Price rises with subscriptions, saved methods, authorisations, several currencies or providers, staff permissions, legacy code, migration or several systems updating together.

Standalone support£25 - £45/moorRun Growthincluded in £199/mo

Support is optional. The payment provider charges its own transaction, currency, dispute and payout fees directly.

Before payment is connected

Payment integration questions.

Can payment be added to the website I already have?

Usually. I can work with WordPress, an HTML site or a bespoke PHP, Node.js or React build when the code and provider access are available. I check the existing form, booking, invoice or account route before choosing a link, embedded checkout or API integration.

Which payment provider should I use?

It depends on the account you already have, the payment methods customers need, the countries and currencies involved, subscriptions or refunds, and what the provider exposes. I can integrate Stripe, PayPal, Worldpay or another suitable documented provider without pretending every provider supports the same workflow.

Will my website store customers’ card numbers?

The normal route is for the payment provider to collect the card details through its secure checkout or payment component. Your website stores the business record, provider reference and status it needs, not raw card numbers.

Can I take a deposit, save a card or place a card hold?

Potentially, but these are different payment behaviours. A charged deposit, a saved payment method and a temporary authorisation each need provider support, clear customer terms and different failure or cancellation handling. The proposal names exactly which behaviour is included.

How are refunds, failed payments and disputes handled?

A contained build can use the provider dashboard, while a connected system can expose approved refund or retry actions to staff. In either case the business record must follow the verified provider status and the proposal states who owns disputes and customer communication.

Can it take recurring subscription payments?

Yes, when the selected provider and business model support them. The build must define the recurring amount, billing frequency, trial or setup charge, failed-renewal route, cancellation and what access changes when a subscription ends.

Bring the current website and payment purpose

Show Ernest what should change after payment.

The first conversation maps amount, customer action, provider, business record, confirmation and recovery. You will know whether a link, embed or custom integration is enough before work is proposed.

Discuss your payment routeExplore every system and add-on Email or telephone only. No obligation and no payment-provider commission to Ernest.
Book a free call WhatsApp