PayID استرالیا: جریان NPP

1) زمینه: NPP و PayID

NPP (New Payments Platform) - زیرساخت پرداخت فوری ملی استرالیا (24/7/365) با تسویه حساب در زمان واقعی و پیام غنی ISO 20022. PayID یک لایه آدرس در بالای NPP است که به شما اجازه می دهد نه با BSB/Account، بلکه با نام مستعار «انسان» پرداخت کنید: شماره تلفن، ایمیل، ABN/ACN یا شناسه سازمان.

• قابلیت همکاری: هر شرکت کننده NPP ↔ هر بانک صادر کننده.
• آدرس مستعار: پرداخت کننده نام PayID را قبل از تأیید می بیند (ضد گمراه کننده).
• فوری و نهایی: اعتبار در حساب بازرگان بلافاصله نمایش داده می شود ؛ بازگشت - یک عملیات جداگانه.
• داده های پرداخت: ISO 20022 با پرداخت راحت (هدف از پرداخت، orderId، و غیره).

2) اعضا و نقش ها

NPP/طرح مسیریابی و قوانین

بانک پرداخت کننده (Payer FI): احراز هویت مشتری، ضد تقلب، ارسال پیام.
Payee bank/acquirer (Payee FI): پذیرش وام، اطلاعیه ها، گزارش.
PSP/fintech: برنامه های خط مقدم، SDK ها، گزارش ها و آشتی برای بازرگانان.
Merchant: دارای PayID (یا اطلاعات بانکی) است، یک درخواست/پیوند به پرداخت کننده ایجاد می کند.

3) پرداخت

انواع PayID: تلفن همراه، ایمیل، ABN/ACN، شناسه سازمان.

• هر PayID با یک نام PayID مرتبط است که پرداخت کننده قبل از تأیید می بیند.
• یک حساب واحد می تواند چندین PayID داشته باشد. قابلیت حمل و نقل بین بانکی توسط روش های مهاجرت پشتیبانی می شود.
• ABN/ACN-PayID برای کسب و کار مناسب است: برای مطابقت با مشخصات شرکت آسان تر است.

4) جریان پرداخت اولیه (NPP/PayID)

P2P (فشار): پرداخت کننده وارد می شود/اسکن PayID گیرنده → می بیند نام PayID → اعتبار را فورا تایید می کند.
P2M (فشار): بازرگان یک PayID را منتشر می کند یا یک deeplink/QR را با مقدار از پیش پر شده و ابرداده صادر می کند.
درخواست برای پرداخت (جمع آوری): بازرگان درخواست پرداخت را آغاز می کند ؛ کاربر در درخواست بانکی تایید می کند.

• برای تجارت الکترونیک، از deeplink/QR با مقدار ثابت و orderId استفاده کنید.
• برای آفلاین، یک PayID استاتیک قابل قبول است، اما یک QR پویا برای هر سفارش بهتر است.

5) PayTo: دستورالعمل های الکترونیکی و autocommissions

• Merchant/PSP بلیط را با پارامترها (پرداخت کننده، حساب، محدودیت ها، فرکانس، توضیحات) ایجاد می کند.
• پرداخت کننده مجوز را در درخواست بانکی خود صادر می کند.
• نوشتن بیشتر به طور خودکار در شرایط مجوز بدون هر مرحله احراز هویت دستی انجام می شود.
• سناریوها: اشتراک، ابزار/telco، برنامه های منظم، صدور صورت حساب مبتنی بر استفاده با سقف.

• محدودیت های بلیط، فرکانس و تاریخ شارژ بعدی را به کاربر نشان دهید.
• نگه داشتن کنترل پنل بلیط (مکث/لغو/به روز رسانی) و قلاب وب در مورد وضعیت.

6) محدودیت ها و کنترل ریسک

• در هر معامله/در روز: آستانه بانک برای NPP/PayID ممکن است متفاوت و متفاوت باشد.
• گیرنده های جدید: محدودیت های شروع و/یا سرعت شاتر کاهش می یابد اغلب در اثر.
• سیاست های طبقه بندی: MCC های فردی/عمودی ممکن است سفت شوند.
• بلیط های PayTo: محدودیت ها در بلیط خود (مقدار، دوره، حداکثر نوشتن) تنظیم می شود.

• مقدار hardcode نیست - نگه داشتن دایرکتوری محدود و به روز رسانی به طور منظم.
• در رابط، در مورد امکان اضافی هشدار می دهند و پیشنهاد تقسیم چک، در صورت امکان.

7) UX و امنیت

تأیید تأیید Payee مانند: نمایش نام PayID خطر خطای گیرنده را کاهش می دهد.
2FA و اتصال دستگاه در بانک پرداخت کننده در زمان مجوز.
ضد تقلب/سرعت: بانک ها قوانین خاص خود را دارند. شکستهای احتمالی «نرم» را در نظر بگیرید.
شفافیت: با UTR/زمان/مقدار/هدف + مخاطبین پشتیبانی را بررسی کنید.
بازگشت مجدد: اگر deeplink باز نشده است، کپی کردن PayID، QR استاتیک و دستورالعمل ها را ارائه دهید.

8) بازگشت و اختلافات

شارژر در معنای کارت وجود ندارد. بازگشت یک معامله اعتباری جدید از تاجر به پرداخت کننده با اشاره به UTR/OrderId اصلی است.
پشتیبانی از بازده جزئی و ردیابی کامل در گزارش ها.
اختلافات از طریق بانک ها/PSP ها و مقررات پشتیبانی حل می شود ؛ ذخیره کردن SLA و جمع آوری شواهد (ورود به سیستم سفارش، تحویل، مکاتبات).

9) ادغام بازرگان: گزینه ها

1. شناسه پرداخت استاتیک

شروع به سرعت، حداقل توسعه.
خطرات: عامل انسانی (وارد کردن مقدار/نظر)، تجزیه و تحلیل ضعیف.

2. پویا QR/deeplink

نسل به منظور: مقدار ثابت، orderId، حواله.
شناسایی بهتر برای هر سفارش، خطاهای کمتر، تبدیل بالاتر.

3. درخواست به پرداخت

«فاکتور» از بازرگان → تایید از پرداخت کننده.
مفید برای صورتحساب، B2B و خدمات متغیر.

4. پی تو (حکم الکترونیکی)

اشتراک/هزینه های تکراری ؛ پرداخت کننده ماموريت را در بانکش مديريت ميکنه.
ما نیاز به صفحه نمایش رضایت, مدیریت محدود, اطلاعیه قبل از نوشتن آف.

• قلاب های وب وضعیت (موفقیت/شکست/در انتظار)، نظرسنجی های مکرر با عقب نشینی.
• جدول عدم انطباق) کلید پرسوجوی orderId + (.
• آشتی با UTR/OrderId/زمان/مقدار.
• API های بازپرداخت و روش های ODR.
• نظارت بر SLA بانک/PSP (تاخیر، موفقیت، کدهای خطا).

10) آشتی و گزارش (ISO 20022، UTR)

UTR (شناسه انتقال منحصر به فرد) - کلید اصلی آشتی ؛ نگه داشتن هر دو پرداخت اصلی و بازگشت.
از زمینه های تخصیص/انتقال ISO 20022 برای orderId، سبد خرید، customerRef استفاده کنید.
پیکربندی روزانه خودکار recon و دوره ای کامل recon.
گزارش PSP: معاملات، وضعیت، بلیط PayTo، بازده، انحراف.

11) تعرفه ها و هزینه ها

برای NPP/PayID هیچ MDR کلاسیک در طرح های کارت وجود ندارد، اما هزینه های ارائه دهنده برای به دست آوردن، ماژول های PayTo، گزارش، بسته های SLA وجود دارد.
هزینه های پشتیبانی/اختلافات، ضد تقلب، نسل QR و میزبانی صفحه deeplink را در نظر بگیرید.

12) گزینه های آفلاین و QR

بازرگان ارائه شده QR (پویا): بهینه برای POS/پرداخت ؛ مقدار و ابرداده به کد محافظت می شود.
QR استاتیک: رمزگذاری PayID بدون مقدار ؛ مبلغ را به صورت دستی وارد کنید.
چاپ بر روی چک/بر روی صفحه: مجاز برای کسب و کارهای کوچک، اما بدتر برای آشتی.

13) پذیرش، AML/CTF و محرمانه بودن

مطابق با AML/CTF (AUSTRAC)، معامله/بلیط ورود به سیستم ذخیره سازی، سطح KYC در PSP.
اعمال غربالگری تحریم/تقلب در سطح PSP، قوانین سرعت، نظارت بر ناهنجاری.
پردازش داده های PayID با توجه به اصول حداقل سازی ؛ فقط آنچه را که برای UX و حسابرسی لازم است نشان دهید.

14) ویژگی های با خطر بالا (از جمله iGaming)

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

15) معماری سرویس دروازه NPP/PayID

API: 'createPaymentIntent', 'generateDynamicQR', 'requestToPay', 'createPayToMention', 'بازپرداخت', 'آشتی', 'webhook'.
قابلیت اطمینان: Retray به صورت نمایی، idempotency، deduplication رویداد.
قابلیت مشاهده: معیارها (موفقیت/شکست/تأخیر)، ردیابی، هشدارها در بانکهای SLA.
امنیت: امضای HMAC از قلاب های وب، IP allowlist، چرخش اسرار، گزارش حسابرسی.
داده ها: دایرکتوری های فردی محدودیت های بانک ها/کانال ها، وضعیت های مجوز PayTo، کارت UTR.

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

1. دریافت فروشنده PayID (یا استخر PayID) از بانک/PSP.
2. یک جریان را انتخاب کنید: QR/deeplink پویا، درخواست به پرداخت و/یا PayTo.
3. پیاده سازی قلاب های وب، idempotence و یک جدول بلیط.
4. فعال کردن UTR-oriented recon (روزانه + کامل)، هشدار با ناهماهنگی.
5. اجرای جریان بازپرداخت (کامل/جزئی)، سیاهههای مربوط ODR.
6. اضافه کردن صفحه نمایش محدودیت UX، پیش نمایش نام PayID، خطاهای قابل فهم.
7. نظارت SLA و داشبورد ارائه دهنده را تنظیم کنید.
8. انجام آزمون های پایان به پایان با بانک های صدور مختلف و سناریوهای PayTo.

خلاصه رزومه

برای پرداخت های یک بار، شرط بندی بر روی QR/deeplink پویا با ابرداده غنی.
برای اشتراک و پرداخت های تکراری، از بلیط های PayTo با مدیریت UX شفاف استفاده کنید.
آیا محدودیت کد سخت نیست: نگه داشتن بانک/PSP پیکربندی و به روز رسانی.
ساخت یک فرایند در اطراف UTR آشتی، ورود به سیستم دقیق و هشدار توسط SLA.