GH GambleHub

Swish سوئد: پرداخت های تلفن همراه

1) سویش چیست

Swish سیستم پرداخت A2A تلفن همراه سوئدی (اپراتور Getswish AB) با 24/7 انتقال فوری است. کاربر معاملات را از طریق شناسه بانکی (SCA) تأیید می کند. سناریوهای P2P (در هر تلفن)، P2M کسب و کار (آنلاین و آفلاین)، کمک های مالی و پرداخت ها پشتیبانی می شوند.

خواص کلیدی:
  • آدرس دهی با شماره تلفن (یا شماره بازرگان/QR)، بدون IBAN در UX.
  • اعتبار فوری به حساب بانکی گیرنده ؛ پایان نامه انتقال بانکی
  • اصطکاک کم: App2App/QR، تایید در شناسه بانکی.
  • پوشش گسترده بانکی و محبوبیت بالا در خرده فروشی/آنلاین.

2) نقش ها و محصولات

Getswish (طرح) - قوانین، کاتالوگ ها و نام تجاری.
بانک های شرکت کننده - صدور/اتصال Swish، اعمال محدودیت ها و ضد تقلب.
PSP/acquirers - اتصال بازرگانان (Swish Handel/Swish Företag)، ارائه API/SDK، گزارش، حل و فصل.

محصولات:
  • Swish P2P - انتقال بین افراد.
  • Swish Företag - قبول پرداخت آنلاین (ویترین/POS).
  • Swish Handel (Swish for e-commerce) - پرداخت آنلاین (QR/App2App/Link).
  • کمک های مالی Swish - شماره های کوتاه/نام مستعار برای کمک های مالی.
  • پرداخت Swish/پرداخت - پرداخت توده (از طریق بانک/PSP).

3) جریان پرداخت

3. 1 P2P (فشار)

1. فرستنده تماس تلفنی را انتخاب می کند → مقدار/پیام را وارد می کند.
2. تایید در شناسه بانکی (چهره/لمس/کد).
3. گیرنده فورا اعتبار در حساب و اطلاع رسانی در برنامه را می بیند.

3. 2 P2M: تجارت الکترونیک (سویش هندل)

دو کانال UX:
  • App2App/Deeplink: در چک کردن, باز کردن برنامه Swish/BankID → تایید → بازگشت به تاجر.
  • QR per-order: یک QR پویا (sum, orderId, merchant reference) تولید می شود ؛ اسکن مشتری با یک دوربین Swish → با BankID تایید می کند.

3. 3 POS/آفلاین (Företag)

QR پویا در پرداخت یا شماره Swish استاتیک (مقدار دستی).
تایید در شناسه بانکی ؛ بررسی - در بازرگان و در درخواست مشتری.

3. 4 درخواست به راو/فاکتورها

Merchant یک لینک/درخواست پرداخت (در ایمیل/SMS/messenger) ارسال می کند ؛ مشتری در شناسه بانکی تایید می کند.

3. 5 پرداخت

کسب و کار مشتری انتقال پول را به یک شماره تلفن از طریق یک بانک/PSP می فرستد ؛ ضد تقلب و محدودیت های خروجی اعمال می شود.

4) وضعیت و زمان بندی

وضعیت های معمولی «آغاز شده» → «در انتظار» → «موفقیت »/« شکست خورده »/« لغو »/« منقضی شده».
برای یک بررسی وب، ممکن است تاخیر در پاسخ برنامه/BankID → نگه داشتن زمان و تکرار وضعیت (نظرسنجی + webhooks) وجود داشته باشد.
حل و فصل برای تاجر - زمان واقعی وام بانکی/به نزدیکترین اسلات عامل بسته به بانک/PSP (برای گزارش، انجام recon روزانه به هر حال).

5) محدودیت ها و سیاست های ریسک

محدودیت ها توسط بانک ها/PSP تعیین می شود و در مشخصات و کانال متفاوت هستند:
  • در هر معامله، در روز/24 ساعت ؛ گاهی اوقات هفتگی/ماهانه.
  • گیرنده جدید/بازرگان جدید - آستانه کاهش/سرعت شاتر.
  • محدودیت های کانال: P2P، تجارت الکترونیک (App2App/QR)، POS، پرداخت.
  • سرعت/دستگاه/قوانین جغرافیایی و نمره ریسک در سمت بانک.
💡 تمرین: آیا «توری» مبالغ سخت نیست. نگه داشتن یک دایرکتوری از محدودیت های بانک ها/کانال ها، به روز رسانی ؛ در UI، یک دلیل روشن برای امتناع («محدودیت بانک/کانال») نشان دهید و گزینه های دیگری را پیشنهاد کنید (تقسیم چک، روش دیگر).

6) اقتصاد و کمیسیون

هزینه برای تاجر معمولا پایین تر از MDR کارت کلاسیک است، اما شرایط بستگی به بانک/PSP (ثابت/کم بهره، هزینه برای QR/SDK/گزارش).
شارژ برای پشتیبانی در انتظار/منقضی شده، اختلافات، شناسایی و نظارت SLA.

7) بازگشت و اختلافات (ODR)

Chargeback به عنوان در کارت وجود ندارد. بازگشت - یک معامله اعتباری جداگانه از بازرگان به مشتری (بازپرداخت جزئی پشتیبانی می شود).
شرایط - بانک (معمولا T + 0/T + 1).
اختلافات - با توجه به روش های بانک/PSP: نگه داشتن سیاهههای مربوط به سفارش، تایید خدمات/تحویل، انطباق جزئیات مشتری.

8) ایمنی و انطباق

SCA از طریق شناسه بانکی، اتصال دستگاه، بررسی سیم کارت/دستگاه توسط بانک.
به حداقل رساندن PII: ذخیره تنها ویژگی های لازم (تلفن/مراجع)، رمزگذاری PII ؛ دسترسی - با توجه به اصل حداقل امتیازات.
Webhooks: HMAC/nonce، حفاظت از پخش، برچسب های زمانی و dedup رویداد.
انطباق با PSD2/GDPR Finansinspektionen و الزامات محلی.

9) ادغام بازرگان

گزینه ها

1. میزبانی/جاسازی شده توسط PSP - شروع سریع، App2App/QR از جعبه، وضعیت و اشکالات.
2. Server-to-Server + App2App/QR - UX بومی، QR پویا در هر سفارش، پردازش خطا/تکرار عمیق.
3. پرداخت توسط لینک/فاکتور - ارسال یک لینک/درخواست ؛ مناسب برای خدمات و B2B.

اجزای پشتیبان مورد نیاز:
  • API: 'createPayment', 'بازپرداخت', 'requestToPay' (در صورت موجود بودن از PSP), 'webhook', 'آشتی'.
  • Idempotence ('orderId' + key)، retrays نمایی، رویداد dedup.
  • Recon: روزانه خودکار recon + دوره ای کامل recon ؛ فروشگاه UTR/مرجع بانکی
  • داشبورد SLA: تبدیل، «در انتظار → موفقیت/منقضی شده»، تاخیر قبل از ثبت نام.

10) آشتی و گزارش

ورود: 'paymentId/transactionId' ارائه دهنده، 'orderId'، کانال (App2App/QR/Link/POS)، شماره گیرنده، وضعیت، مقدار/ارز، برچسب زمان، UTR.
از PSP/بانک: ثبت اعتبار/بازده/اصلاحات، به روز رسانی وضعیت اواخر.
شامل هشدار برای خارج از همگام سازی و ناهنجاری (دو نوشتن آف، حلق آویز 'در انتظار').

11) الگوهای UX

همراه اول: App2App خودکار پیشنهاد ؛ بر روی دسکتاپ - یک QR پویا بزرگ با یک تایمر.
خطاهای شفاف: محدودیت، خرابی BankID، اتمام وقت ؛ تکرار ایمن و جایگزین (card/SEPA/A2A از ارائه دهنده دیگر).
دریافت: مقدار، زمان، 'شناسه معامله'، کانال، UTR، مخاطبین پشتیبانی.
تایمر عمل برای QR/درخواست و اسکریپت بازیابی انقضا.

12) عود و حکم

Basic Swish - یک بار با SCA. برای اشتراک, یک بسته نرم افزاری استفاده می شود: اولین پرداخت Swish → e-حکم/Autogiro/بانکداری باز PIS برای بدهی بیشتر (حد/فرکانس/اطلاعیه, صفحه نمایش مدیریت بلیط).

13) عمودی با ریسک بالا (از جمله iGaming)

در دسترس بودن و محدودیت کانال در سیاست بانک/PSP و قانون محلی بستگی دارد.
انتظار می رود آستانه های کاهش یافته، KYC گسترش یافته و ممکن است نگه داشته شود.
برنامه ریزی ریل های جایگزین (کارت، SEPA، دیگر PIS) و مسیریابی هوشمند توسط ریسک/بانک/کانال.

14) معماری «Swish Gateway»

لایه API (REST/GraphQL) برای ثبت نام نقدی و backhoe.
صف های رویداد: رویدادهای وضعیت → صورتحساب/CRM/تجزیه و تحلیل.
امنیت: طاق برای اسرار، PSP IP allowlist، اعتبار سنجی تغییر مسیر-URI دقیق، نشانه های ضد پخش.
قابلیت مشاهده: تبدیل کانال (App2App/QR/POS/Link)، کسری از «در انتظار → منقضی شده»، زمان برای حل و فصل/بازگشت.

15) چک لیست خروجی

1. PSP/بانک را با Swish Handel/Företag وصل کنید. موافقت نرخ/SLAs و کانال (App2App/QR/POS/لینک).
2. پیاده سازی 'createPayment' + QR/App2App پویا, خطا/صفحه نمایش حد.
3. اتصال webhooks، idempotency، retray و رویداد dedup.
4. راه اندازی recon (روزانه + کامل)، UTR/fin منابع ذخیره سازی.
5. امکان بازپرداخت جزئی/کامل و روش ODR.
6. داشبورد SLA و هشدار برای تبدیل/تاخیر/وضعیت آویزان را اجرا کنید.
7. انجام تست e2e با بانک های اصلی/دستگاه ها، POS (در صورت لزوم).


محدود کردن کارت مرجع

💡 آستانه واقعی بانک/PSP را تعریف می کند و بر اساس سناریو متفاوت است.

Per-txn/24h/7d: در پیکربندی ذخیره کنید و قبل از شروع بررسی کنید.
گیرندگان/بازرگانان جدید: آستانه پایین/سرعت شاتر.
کانال ها: محدودیت های جداگانه برای P2P، تجارت الکترونیک (App2App/QR)، POS، پرداخت.
سرعت/خطر: ضد سرقت بانک می تواند به آرامی عملیات را کاهش دهد.


خلاصه رزومه

برای آنلاین - App2App + QR پویا، برای آفلاین - QR/POS (Företag)، برای انتقال - P2P به تلفن.
تایید آنلاین جداگانه و اعتبار نهایی در منطق کسب و کار ؛ ساخت در اطراف webhooks + recon و بازپرداخت جزئی.
مقدار را ثابت نکنید: حفظ تنظیمات محدود توسط بانک ها/کانال ها با به روز رسانی منظم.
برای اشتراک، اولین بسته نرم افزاری Swish → یک بلیط با مدیریت شفاف و اطلاعیه ها.

Contact

با ما در تماس باشید

برای هرگونه سؤال یا نیاز به پشتیبانی با ما ارتباط بگیرید.ما همیشه آماده کمک هستیم!

شروع یکپارچه‌سازی

ایمیل — اجباری است. تلگرام یا واتساپ — اختیاری.

نام شما اختیاری
ایمیل اختیاری
موضوع اختیاری
پیام اختیاری
Telegram اختیاری
@
اگر تلگرام را وارد کنید — علاوه بر ایمیل، در تلگرام هم پاسخ می‌دهیم.
WhatsApp اختیاری
فرمت: کد کشور و شماره (برای مثال، +98XXXXXXXXXX).

با فشردن این دکمه، با پردازش داده‌های خود موافقت می‌کنید.