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.

Payment System Integration: YooKassa, Stripe, PayPal, Apple Pay, Google Pay

Conversion dropped by 12% immediately after the redesign. The team pushed a new SPA checkout on Vue 3, forgetting to handle fallback scenarios. Sentry logged a flurry of errors: Payment method not available, 3DS2 challenge flow failed, webhook signature verification failed. Users abandoned carts at the payment method selection stage. Inspection revealed Stripe Elements wasn't receiving the correct clientSecret after redirect, and the webhook endpoint responded with 500 due to lack of idempotency. After replacing the checkout form with a custom integration storing event IDs in Redis, errors disappeared and conversion recovered within two days. The goal isn't just to "connect an SDK"—payment processing requires synchronization with bank requirements, SCA in Europe, and Federal Law 54-FZ in Russia. Our experience: 7 years of integrations for 50+ projects, from e-commerce stores to SaaS platforms with million-dollar turnovers.

What's Included in Turnkey Work

• Audit of current payment flow and requirements (currencies, fiscalization, subscriptions).
• Provider selection based on geography and business model.
• Backend integration (Laravel/Node.js/Go) with webhook handling, idempotency, and retries.
• Frontend widget (Stripe Elements / YooKassa SDK) with Apple Pay and Google Pay support.
• Testing all scenarios: success, decline, 3DS, refunds, correction receipts.
• Monitoring of first transactions and documentation.

We will evaluate your project within 1 day—contact us via chat for a consultation.

Provider Comparison: Which to Choose

Stripe wins on flexibility: 135+ currencies vs. YooKassa's single currency. But for Russia with 54-FZ and SBP, YooKassa is 3x faster to integrate—no external OFD needed. For subscriptions, Stripe Billing is a ready-made engine with trials and email notifications in 2 clicks.

How to Choose the Right Provider?

Three key points. Where do your clients live? Only Russia → YooKassa; globally → Stripe. Do you need 54-FZ fiscalization? Yes → YooKassa; otherwise Stripe + cloud OFD. Do you plan subscriptions? Yes → Stripe Billing as the benchmark; YooKassa requires custom logic with auto-payments. Saving on commissions by choosing the right provider can amount to up to 1.5% of turnover. For a project with 2 million RUB per month, that's 360,000 RUB per year.

Where the Real Difficulties Lie

Setting up a test mode takes an hour. Properly handling all scenarios takes weeks.

Webhook reliability. A webhook may not arrive—server unavailable, timeout, network issues. The provider retries with exponential backoff (Stripe up to 3 days). The handler must be idempotent: if payment.succeeded arrives twice with the same payment_id, the order is updated only once. This is implemented by storing event IDs in Redis with a TTL.

3DS2 and redirect flow. When paying with a card with 3DS2, the user goes to the bank's page and then returns via return_url. During this time, the session may expire or the cart may be cleared. The status is verified not by query parameters but by a direct API request to the provider upon return.

Partial refunds and receipts. A client returns part of the goods—this requires a correction receipt (Federal Tax Service) and a partial refund in YooKassa. Stripe natively supports partial_refund. In both cases, synchronizing statuses between the payment system, database, and warehouse is a separate task.

Currency limitations. YooKassa only handles rubles. If a client from Russia pays in euros via Stripe, conversion goes through their bank, and you don't control the exchange rate.

Why Do Webhooks Require Idempotency?

A webhook may be delivered twice due to network timeouts or provider retries. Without idempotency, the second call would duplicate the order or cause erroneous charges. The solution is to store a unique event ID (e.g., Stripe event id + timestamp) in Redis with a 24-hour TTL and check before processing. If the ID already exists, return 200 without executing business logic. Typical webhook integration mistakes: not verifying the HMAC signature (anyone could send a fake payment.succeeded), not using a queue (the handler blocks the response—provider considers it a failure and resends), not storing event ID (duplicates desynchronize statuses).

How We Build the Integration

Architecture. We never store card data—only tokens from the provider. Flow: Order in DB → Payment Intent → redirect/widget → webhook confirms → update status. The source of truth is the status in the payment system.

For Laravel we use stripe/stripe-php or yookassa-sdk. Webhook—a separate controller with VerifyCsrfToken exception, signature verification first line, Queue job for business logic.

For Next.js/React—@stripe/stripe-js + @stripe/react-stripe-js. PaymentElement includes Apple/Google Pay automatically. Example:

const stripe = await stripePromise;
const { error } = await stripe.confirmPayment({
  elements,
  confirmParams: { return_url: 'https://example.com/order/thank-you' },
});

Testing. Stripe CLI: stripe listen --forward-to localhost:8000/webhook. Test cards for all scenarios (3DS, decline, insufficient funds). Cypress checkout flow test in CI—mandatory stability guarantee.

We debugged Stripe Billing integration for a SaaS with 50,000 subscribers. The issue was handling invoice.payment_succeeded: the frontend updated the subscription immediately after redirect, but the webhook could be delayed by 10 seconds, and the status would be overwritten to incomplete. Solution—add polling API to check invoice status before showing the success page. This reduced erroneous cancellations by 18%.

Process and Timeline

Audit → provider selection → backend → frontend → tests → deploy → monitoring.

Pricing is custom. Order integration and your checkout won't crash on the next update.

Links:

• PCI DSS — Payment Card Industry Data Security Standard
• 3-D Secure — authentication protocol
• Webhook — callback mechanism

We guarantee: 7 years of experience, 50+ successful integrations. Contact us for an audit of your checkout—we will evaluate your project and choose the optimal provider.