PayBridge — Development Story

CLIENT

About the client

The payment service provider leading Japan's payment-agency market.

The payment service provider is a B2B business that supplies payment capabilities to EC merchants across Japan. Its merchants run on a wide range of EC platforms (SFCC / EC-CUBE 2.x / EC-CUBE 4.x), each requiring a separately developed and maintained payment plugin.

Aiming to “deliver the same payment capabilities uniformly, regardless of the EC platform,” we built a shared payment-plugin foundation in-house. Platform differences are absorbed by a thin UI layer, while payment logic, Webhook handling, tokenization, and 3DS are implemented in a shared core.

Supported EC platforms

3 Platforms (SFCC + EC-CUBE 2/4)

Supported payment methods

5+ types

Security compliance

3DS + PCI-DSS

BUSINESS FLOW

STEP

Merchant onboarding

Install the plugin matched to your EC platform

STEP

Unified Checkout

Choose from 5+ payment methods in a single UI

STEP

Payment processing + Webhook

Tokenization, 3DS support, and instant sync via Webhook

STEP

Merchant management

Run transaction history and refunds from one admin panel

CHALLENGE

Design challenges to solve

The four structural requirements demanded of the plugin.

None of these is a technology-choice issue — each is a business requirement tied directly to development efficiency, operating cost, security, and merchant onboarding time.

① Implementing separately per EC platform triples development cost

The same payment logic on SFCC / EC-CUBE 2 / EC-CUBE 4 implemented three times , maintenance cost balloons threefold too.

② Without absorbing SDK differences, version gaps cause behavioral inconsistencies

Leaving official-SDK version gaps unaddressed,a production outage from a minor update becomes a real risk.

③ Implementing Webhooks per platform makes state sync unstable

If a Webhook handler is implemented per EC platform,retries and idempotency guarantees get fragmented.

④ Delaying merchant onboarding stalls the payment-agency business

If onboarding to one platform takes weeks,merchant acquisition speed falls behind rival payment providers.

ARCHITECTURE

The architecture we built together

Turning the payment plugin into an “unstoppable foundation” across four domains.

We built the payment service provider's payment-plugin foundation in-house from scratch. Three official-SDK-compliant plugins for the EC platforms are delivered as a single plugin suite: payment logic is centralized in a shared core, while the UI layer is implemented in each platform's template language.

Domain ①

Shared payment core

Challenge

Implementing separately per EC platform triples development cost.

Solution

Payment logic, tokenization, and 3DS centralized in a shared core

Each platform's plugin implements only the UI layer; payment logic lives in a shared module

Domain ②

SDK compatibility

Challenge

Without absorbing SDK differences, version gaps cause behavioral inconsistencies.

Solution

Official-SDK compliance + a compatibility adapter layer

Compliant with the official APIs of SFRA 6.x / EC-CUBE 2.25 / 4.3; version differences absorbed by adapters

Domain ③

Webhook integration

Challenge

Implementing Webhooks per platform makes state sync unstable.

Solution

A unified Webhook handler guarantees idempotency + retries

A Webhook receiving spec shared across all 3 platforms; retries, timeouts, and idempotency implemented in one place

Domain ④

Merchant onboarding

Challenge

Delaying merchant onboarding stalls the payment-agency business.

Solution

Plugin distribution via npm/composer + setup wizard

Merchants finish onboarding in a few clicks, choosing API keys and payment methods in a config UI

TECH STACK

SFCC

Salesforce Commerce Cloud

JavaScriptI ISML templates

EC-CUBE

PHP

Symfony (EC-CUBE 4)T Twig / Smarty

Composer

Shared

R REST APIW Webhook3 3D SecureP PCI-DSS

IMPACT

The value the platform creates

The payment service provider's “merchant acquisition speed” accelerates.

This foundation continuously produces business outcomes — lower development cost, SDK compatibility, faster merchant acquisition — not just technical metrics.

① A foundation that compresses development and maintenance cost

Payment logic is consolidated into a shared core, so each EC-platform plugin only needs a UI layer. Maintenance cost drops sharply.

② A design that auto-adapts to SDK version differences

Even when the official SDK updates, the adapter layer absorbs it — the plugin keeps working.

③ An architecture that shortens merchant onboarding time

With plugin distribution plus a setup wizard, merchants can enable payments in just a few clicks.

④ A design that handles payment data securely

With 3D Secure + PCI-DSS compliance, card data is tokenized — reducing operational risk for merchants.

A different payment implementation per EC platform,one unified plugin foundation.

The payment service provider leading Japan's payment-agency market.

The four structural requirements demanded of the plugin.

Turning the payment plugin into an “unstoppable foundation” across four domains.

The payment service provider's “merchant acquisition speed” accelerates.

Experience the payment service provider's product through a live, working demo.