Custom Payment Form Integration

The payment form is the point where a user either becomes a customer or leaves forever. We build an embedded payment form that keeps the site context and doesn't force the user to redirect to third-party pages. No foreign-looking redirects, cryptic error messages, or fields that reset after a failed attempt. Our goal is to embed payment acceptance directly into the site interface so the user stays on the page and trusts the process.

According to our data, an embedded form increases conversion by 15–20% compared to redirect, and the average order value grows by 27%. Abandonment drops by half. With over 10 years of experience and 40+ payment integrations, our approach is battle-tested.

How does the embedded form work?

Modern payment gateways offer two integration options: redirect to the gateway page and an embedded widget. The embedded option is preferable — it retains visual context and boosts trust. Here are code examples for Stripe and CloudPayments:

// Stripe Payment Element const stripe = Stripe('pk_live_...'); const elements = stripe.elements({ appearance: { theme: 'flat', variables: { colorPrimary: '#0f172a', fontFamily: 'Inter, sans-serif', }, }, }); const paymentElement = elements.create('payment', { layout: { type: 'tabs', defaultCollapsed: false }, }); paymentElement.mount('#payment-element'); const form = document.getElementById('payment-form'); form.addEventListener('submit', async (e) => { e.preventDefault(); const { error } = await stripe.confirmPayment({ elements, confirmParams: { return_url: 'https://example.com/order/complete', }, }); if (error) showError(error.message); }); // CloudPayments widget var widget = new cp.CloudPayments(); widget.charge({ publicId: 'pk_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx', description: 'Order #12345', amount: 4990, currency: 'RUB', invoiceId: '12345', email: '[email protected]', skin: 'mini', data: { orderId: '12345', userId: 42 }, }, function (options) { updateOrderStatus(options.invoiceId, 'paid'); }, function (reason, options) { logPaymentError(reason, options); } ); 

How does the server create a payment intent?

No amount logic should come from the client side. The browser cannot be trusted with a hidden field — it can be tampered with. The server creates a payment intent with the actual amount from the database:

// Laravel — creating a PaymentIntent via Stripe use Stripe\StripeClient; public function createPaymentIntent(Request $request): JsonResponse { $order = Order::findOrFail($request->order_id); abort_if($order->user_id !== auth()->id(), 403); $stripe = new StripeClient(config('services.stripe.secret')); $intent = $stripe->paymentIntents->create([ 'amount' => $order->total_cents, 'currency' => 'rub', 'metadata' => [ 'order_id' => $order->id, 'user_id' => $order->user_id, ], 'automatic_payment_methods' => ['enabled' => true], ]); return response()->json([ 'client_secret' => $intent->client_secret, ]); } 

The client receives only the client_secret — it contains no amount, and cannot be used to alter parameters.

Why is the webhook the single source of truth?

The frontend form reports success, but that is not guaranteed. Funds may get stuck, or the bank may reject the transaction after redirect. The only reliable source is the webhook from the payment gateway:

// Stripe webhook handler public function handleWebhook(Request $request): Response { $payload = $request->getContent(); $sigHeader = $request->header('Stripe-Signature'); try { $event = \Stripe\Webhook::constructEvent( $payload, $sigHeader, config('services.stripe.webhook_secret') ); } catch (\Stripe\Exception\SignatureVerificationException $e) { return response('Invalid signature', 400); } match ($event->type) { 'payment_intent.succeeded' => $this->handlePaymentSucceeded($event->data->object), 'payment_intent.payment_failed' => $this->handlePaymentFailed($event->data->object), 'charge.dispute.created' => $this->handleDispute($event->data->object), default => null, }; return response('OK', 200); } private function handlePaymentSucceeded(\Stripe\PaymentIntent $intent): void { $order = Order::where('stripe_payment_intent', $intent->id)->firstOrFail(); $order->update(['status' => 'paid', 'paid_at' => now()]); dispatch(new SendReceiptJob($order)); dispatch(new InitiateShippingJob($order)); } 

How to ensure card data security?

Card data must never pass through your server — only through the payment gateway's iframe or its JavaScript library. This complies with PCI DSS SAQ A, the simplest level for merchants. If card data ever touches your application, even for a millisecond, you jump to SAQ D with annual audits and hundreds of mandatory requirements.

Recommended Content Security Policy for pages with the payment form:

Content-Security-Policy: default-src 'self'; script-src 'self' https://js.stripe.com https://widget.cloudpayments.ru; frame-src https://js.stripe.com https://widget.cloudpayments.ru; connect-src 'self' https://api.stripe.com; 

Comparison: redirect vs embedded form

Payment gateway comparison

Stripe wins on the number of payment methods, but for Russia, CloudPayments or YooKassa are preferable due to native SBP and fiscalization support.

UX details that affect conversion

Real-time validation

The card number should be formatted in groups of 4 digits as the user types. Expiry date should auto-add a slash. If the Luhn check fails, notify immediately — don't wait for submit.

Preserve progress

If the user filled in email, name, address — and the payment form fails with an error, all fields should remain. Clear only the CVV (PCI DSS requirement).

State indication

The "Pay" button should show a spinner during the request and be disabled to prevent double clicks. Double payments are a real problem.

Mobile keyboard

The card number field should bring up the numeric keypad (inputmode="numeric"), not the alphabetic one. This small detail is often forgotten.

<input type="text" inputmode="numeric" autocomplete="cc-number" placeholder="0000 0000 0000 0000" pattern="[0-9\s]{13,19}" /> 

Supporting multiple payment methods

Stripe Payment Element shows cards, Apple Pay, Google Pay, SEPA, Klarna out of the box — automatically based on the user's country and browser. CloudPayments supports cards, SBP, Tinkoff Pay. SBP is particularly useful: lower fees, high conversion on mobile, and no need to enter card details.

Configuring Apple Pay via CloudPayments requires domain verification — place a file at /.well-known/apple-developer-merchantid-domain-association. This is an Apple requirement.

What's included in the integration

• Merchant account setup
• Server-side implementation: payment intent creation, webhook handling
• Client-side form with validation, responsive layout, and state indication
• Testing with test cards
• Operation manual and launch support

Timeline and stages

A typical integration for one gateway takes 3–5 business days. We work iteratively: analysis → design → implementation → testing → deploy. Adding a second gateway (e.g., for fallback) takes another 2–3 days. Fiscalization integration is a separate task, taking 2–4 days if the gateway supports it.

Request a custom payment form development — we will implement the integration quickly. Get a consultation on your project by writing to us.