Єдиний платіжний модуль для міні-програм Super App

Реалізація єдиного платіжного модуля для всіх міні-програм Super App

Ми розробляємо єдиний платіжний модуль для Super App, який централізує обробку транзакцій для всіх міні-програм. Кожен міні-додаток хоче приймати платежі, але розрізнені інтеграції з провайдерами створюють проблеми: розширюється scope PCI DSS, оновлення сертифікатів або ключів API вимагає синхронного деплою всіх міні-програм, у користувача немає єдиної історії платежів. Наш підхід вирішує ці завдання за допомогою bridge-архітектури, яка ізолює платіжну логіку в shell-додатку.

Досвід нашої команди в розробці платіжних систем — понад 5 років, ми реалізували централізовані платіжні модулі для 10+ Super App у ритейлі та фінтехі. Результат: скорочення часу інтеграції кожної нової міні-програми до 3 днів (що в 5-10 разів швидше за децентралізований підхід) і зниження витрат на підтримку платіжного скоупу на 60%. Наприклад, наш клієнт з маркетплейсом зекономив $120 000 на рік після впровадження модуля. Замовте аудит архітектури вашого Super App — ми підготуємо індивідуальний план та оцінимо вартість проекту під ключ.

Як виглядає типова взаємодія shell і міні‑програми?

Super App будується на WebView (або React Native / Flutter WebView) для міні-програм. Платіжний bridge реалізується через інтерфейс, зареєстрований у WebView. На Android використовується addJavascriptInterface, на iOS — WKScriptMessageHandler. Міні-програма викликає нативний платіжний екран shell-додатку через bridge API.

// Android Shell App: реєстрація bridge-методу webView.addJavascriptInterface(PaymentBridge(this), "NativePayment") class PaymentBridge(private val activity: AppCompatActivity) { @JavascriptInterface fun initiatePayment(requestJson: String) { val request = PaymentRequest.fromJson(requestJson) activity.runOnUiThread { PaymentBottomSheet.show(activity, request) { result -> val js = "window.onPaymentResult(${result.toJson()})" webView.evaluateJavascript(js, null) } } } @JavascriptInterface fun getSavedPaymentMethods(): String { return paymentRepository.getSavedMethods().toJson() } } 

// Міні-програма (JS/React): виклик платіжного модуля async function checkout(amount, orderId) { return new Promise((resolve, reject) => { window.onPaymentResult = (result) => { if (result.status === 'success') resolve(result); else reject(result.error); }; NativePayment.initiatePayment(JSON.stringify({ amount, currency: 'RUB', orderId, miniProgramId: 'com.yourshop.miniapp' })); }); } 

На iOS аналогічна схема через WKScriptMessageHandler:

class PaymentMessageHandler: NSObject, WKScriptMessageHandler { func userContentController( _ controller: WKUserContentController, didReceive message: WKScriptMessage ) { guard message.name == "initiatePayment", let body = message.body as? [String: Any] else { return } let request = PaymentRequest(from: body) PaymentCoordinator.shared.present(request: request, from: hostViewController) { result in let js = "window.onPaymentResult(\(result.jsonString))" webView.evaluateJavaScript(js) } } } // Реєстрація в WKWebViewConfiguration configuration.userContentController.add(PaymentMessageHandler(), name: "initiatePayment") 

Чому централізація знижує витрати на підтримку?

Централізація скорочує трудозатрати в 5–10 разів на кожну міні-програму та зводить до мінімуму ризики при аудиті PCI DSS.

Порівняння провайдерів: коли потрібен роутинг

Єдиний PaymentCoordinator

Ключовий компонент — PaymentCoordinator у Shell App. Він знає: які методи оплати доступні (картки, Apple Pay / Google Pay, СБП, баланс Super App), які картки збережено для користувача, і який провайдер обслуговує платіж (один або кілька).

// Android: PaymentCoordinator як singleton у Shell class PaymentCoordinator private constructor() { companion object { val shared = PaymentCoordinator() } private val activeProviders = mutableMapOf<String, PaymentProvider>() fun registerProvider(id: String, provider: PaymentProvider) { activeProviders[id] = provider } fun initiatePayment(request: PaymentRequest, callback: (PaymentResult) -> Unit) { val provider = selectProvider(request) provider.process(request, callback) } private fun selectProvider(request: PaymentRequest): PaymentProvider { // Логіка маршрутизації: різні міні-програми можуть використовувати різних провайдерів return activeProviders[request.miniProgramId] ?: activeProviders["default"] ?: throw IllegalStateException("No payment provider registered") } } 

Маршрутизація за miniProgramId дозволяє одному Super App працювати з кількома еквайрами — один для маркетплейсу, інший для сервісу доставки, третій для фінансових послуг.

Збережені методи оплати (Saved Payment Methods)

Користувач додає картку один раз — вона доступна у всіх міні-програмах. Зберігати токени карток потрібно централізовано:

data class SavedPaymentMethod( val id: String, val type: PaymentMethodType, // CARD, SBP, APPLE_PAY val displayName: String, // "Visa •••• 4242" val providerToken: String, // токен конкретного провайдера (не PAN!) val isDefault: Boolean ) data class PaymentRequest( val amount: Long, // у копійках val currency: String, val orderId: String, val miniProgramId: String, val miniProgramName: String, // "Доставка YourShop" — для відображення користувачеві val allowedMethods: List<PaymentMethodType>? = null // null = всі доступні ) 

providerToken — це токен від Stripe (pm_xxx), CloudPayments або іншого провайдера. PAN ніколи не зберігається на пристрої. Синхронізація між пристроями здійснюється через сервер, прив'язаний до userId.

UI єдиного платіжного екрану

Bottom Sheet з платіжними методами консистентний для всього Super App. Різні міні-програми не можуть змінювати його зовнішній вигляд — це важливо для довіри користувача.

Єдиний платіжний екран вміє:

• показувати список збережених карток з вибором;
• додавати нову картку (через SDK провайдера або власний card input);
• обробляти Apple Pay / Google Pay в один дотик;
• СБП з deeplink у банківський додаток;
• відображати суму та назву міні-програми (звідки запит).

Обробка помилок та retry

Платіж — критична операція. Shell App правильно обробляє часткові відмови:

• Таймаут провайдера → показати «Статус платежу уточнюється», запустити polling статусу.
• 3DS-редирект → відкрити WebView всередині bottom sheet, не виводити користувача з додатку.
• Дублювання запиту → ідемпотентний orderId на стороні сервера.

Гарантуємо коректну обробку всіх сценаріїв, включаючи скасування платежу користувачем та втрату з'єднання.

Типові помилки при самостійній реалізації

• Відсутність ідемпотентності: повторний виклик платіжного API створює дублюючий платіж. Рішення — використовувати унікальний orderId на рівні модуля.
• Зберігання PAN на пристрої: пряме порушення PCI DSS. Завжди використовуйте токени провайдера.
• Ізольований UI для кожної міні-програми: користувач втрачає довіру. Єдиний bottom sheet — обов'язковий.

Що входить у роботу

1. Аналіз архітектури вашого Super App та кількості міні-програм.
2. Проектування bridge API (iOS/Android) та контрактів PaymentRequest/PaymentResult.
3. Реалізація PaymentCoordinator з підтримкою одного або кількох провайдерів.
4. Розробка єдиного платіжного UI (Bottom Sheet) з підтримкою Apple Pay, Google Pay, СБП, карток.
5. Інтеграція токенізації та збережених методів оплати.
6. Тестування з двома пілотними міні-програмами.
7. Документація bridge API для розробників міні-програм.
8. Підтримка при проходженні сертифікації App Store та Google Play (перевірки In-App Purchase, ATT).

Орієнтовні терміни та вартість

3–6 тижнів — від аналізу до релізу в двох міні-програмах. Вартість — від $15 000 під ключ. Щоб отримати попередній план та оцінку, пишіть на [email protected] або заповніть форму на сайті. Наші інженери мають сертифікати з iOS та Android розробки, забезпечуючи відповідність останнім вимогам App Store Review Guidelines та Google Play політик. Ми гарантуємо, що ваш Super App пройде модерацію з першого разу.