PayID Австралия: NPP ағындары

1) Контексті: NPP және PayID

NPP (New Payments Platform) - нақты уақыт режиміндегі есеп айырысулары және ISO 20022-хабарына бай Австралияның ұлттық жедел төлем инфрақұрылымы (24/7/365). PayID - NPP үстіндегі мекенжай қабаты, ол BSB/Account бойынша емес, «адами» алиас бойынша: телефон нөмірі, email, ABN/ACN немесе Organisation ID бойынша төлеуге мүмкіндік береді.

• Интероперабельділік: NPP-ға кез келген қатысушы кез келген эмитент банктер.
• Алиас адресі: төлеуші расталғанға дейін PayID Name көреді (anti-misdirection).
• Сәттілік және аяқталу: мерчанттың шотындағы кредит бірден көрсетіледі; қайтару - жеке операциямен жүзеге асырылады.
• Төлем деректері: ыңғайлы ремиттенспен ISO 20022 (төлем мақсаты, orderId және т.б.).

2) Қатысушылар мен рөлдер

NPP/схема: бағыттау және ережелер.
Төлеушінің банкі (Payer FI): клиентті аутентификациялау, антифрод, хабарламаны жіберу.
Алушының/эквайердің банкі (Payee FI): кредитті, хабарламаны, есептілікті қабылдау.
PSP/финтех: алдыңғы қосымшалар, SDK, есептер және merchants үшін reconciliation.
Мерчант: PayID (немесе банк деректемелері) ұстайды, төлеушіге сұрау/сілтеме жасайды.

3) PayID идентификаторлары

PayID түрлері: мобильді, email, ABN/ACN, Organisation ID.

• Әрбір PayID растау алдында төлеуші көретін PayID Name салыстырылған.
• Бір шотта бірнеше PayID болуы мүмкін; банктер арасындағы төзімділік көші-қон рәсімдерімен қолдау табады.
• Бизнес үшін ABN/ACN-PayID ыңғайлы: компанияның профиліне сәйкес келу оңай.

4) Төлемнің негізгі ағындары (NPP/PayID)

P2P (push): төлеуші алушының PayID енгізеді/сканерлейді → PayID Name → растайды → дереу кредит.
P2M (push): merchant PayID жариялайды немесе алдын ала толтырылған сомасы мен метадеректері бар deeplink/QR береді.
Request-to-Pay (collect): сатушы төлемге сұрау салуды бастайды; пайдаланушы банк қосымшасында растайды.

• e-commerce үшін тіркелген сомасы мен orderID бар deeplink/QR пайдаланыңыз.
• Офлайн үшін статикалық PayID, бірақ жақсы - динамикалық QR per-order.

5) PayTo: e-mandates және автожазба

• Мерчант/PSP параметрлері бар мандат құрады (төлеуші, шот, лимиттер, кезеңділік, сипаттама).
• Төлеуші мандатты өзінің банктік қосымшасында авторизациялайды.
• Одан әрі есептен шығару мандат шарттары шеңберінде автоматты түрде әрбір базалық қолмен сәйкестендірусіз жүргізіледі.
• Сценарийлер: жазылу, коммуналдық/жеке, тұрақты жоспарлар, төбесі бар usage-based биллинг.

• Пайдаланушыға мандат лимиттерін, жиілігін және келесі есептен шығару күнін көрсетіңіз.
• Мандаттарды басқару тақтасын (pause/cancel/update) және мәртебелер туралы веб-хоктарды ұстаңыз.

6) Лимиттер және тәуекел-бақылау

• Per-transaction/Per-day: NPP/PayID үшін банктік шектер әртүрлі және өзгеруі мүмкін.
• Жаңа алушылар: төмендетілген бастапқы лимиттер және/немесе төзімділік жиі қолданылады.
• Санаттық саясат: жекелеген МСС/тігінен қатаңдату болуы мүмкін.
• PayTo-мандаттар: лимиттер мандаттың өзінде қойылады (сома, кезең, ең көп есептен шығару).

• Соманы хардкодқа алмаңыз - лимиттер анықтамалығын сақтаңыз және үнемі өзектендіріңіз.
• Интерфейсте мүмкін болатын арту туралы ескертіңіз және егер бұл мүмкін болса, чектерді бөлшектеуді ұсыныңыз.

7) UX және қауіпсіздік

Confirmation of Payee - ұқсас тексеру: PayID Name бағдарламасын көрсету адресаттың қате қатесін азайтады.
2FA және device binding авторизациялау сәтінде төлеушінің банкінде.
Антифрод/velocity: банктердің өз ережелері; мүмкін болатын «жұмсақ» істен шығуларды ескеріңіз.
Ашықтық: UTR/уақыт/сома/мақсат + қолдау контактілері бар чек.
Fallback: егер deeplink ашылмаса, PayID көшірмесін, статикалық QR және нұсқауларды ұсыныңыз.

8) Қайтарымдар мен пікірталастар

Чарджбэк карточкалық мағынада жоқ. Қайтару - бұл бастапқы UTR/OrderId сілтемесі бар төлеушіге мерчанттан жаңа кредиттік транзакция.
Есептерде ішінара қайтаруды және толық трассалануды қолдаңыз.
Диспуттар банктер/PSP және қолдау регламенттері арқылы шешіледі; SLA-ны және дәлелдемелерді жинауды (тапсырыс журналы, жеткізу, хат алмасу).

9) Мерчанттың интеграциясы: нұсқалар

1. Статикалық PayID

Тез бастау, минималды әзірлеу.
Тәуекелдер: адами фактор (соманы/түсініктемені енгізу), талдаудан әлсіз.

2. Динамикалық QR/deeplink

Тапсырысқа генерация: белгіленген сома, orderId, ремиттенс.
Үздік per-order recon, аз қателер, жоғары конверсия.

3. Request-to-Pay

Төлем жасаушыдан «шот» → растау.
Инвойсинг, В2В және ауыспалы сомасы бар қызметтер үшін қолайлы.

4. PayTo (e-mandates)

Жазылу/тұрақты есептен шығару; төлеуші мандатты өз банкінде басқарады.
Келісім экрандары, лимиттерді басқару, есептен шығару алдындағы хабарламалар қажет.

• (success/failure/pending), backoff бойынша қайталама сауалнамалар.
• Сәйкестік кестесі (orderId + сұрау кілті).
• UTR/OrderId/уақыт/сома бойынша Reconciliation.
• Refund API және ODR-процедуралар.
• Банктердің SLA/PSP мониторингі (жасырындылық, табыс, қате кодтары).

10) Салыстыру және есептілік (ISO 20022, UTR)

UTR (аударманың бірегей сәйкестендіргіші) - салыстырып тексерудің басты кілті; бастапқы төлемде де, қайтаруда да сақтаңыз.
orderId, себет, customerRef үшін ISO 20022 тағайындау/ремиттенс өрістерін пайдаланыңыз.
daily auto-recon (операциялық) және мерзімді full-recon (қаржылық) баптаңыз.
PSP есептері: транзакциялар, мәртебелер, PayTo мандаттары, қайтарымдар, ауытқулар.

11) Тарифтер мен шығындар

NPP/PayID үшін карта-схемалардағыдай классикалық MDR жоқ, бірақ эквайринг үшін провайдерлік алымдар, PayTo модульдері, есептілік, SLA-пакеттер бар.
Қолдау/пікірталас, антифрод, QR генерациясы және deeplink-беттерді хостинг шығындарын ескеріңіз.

12) Оффлайн нұсқалары және QR

Merchant-presented QR (динамикалық): POS/касса үшін оңтайлы; сомасы және метадеректер кодқа тігілген.
Статикалық QR: сомасыз PayID кодтайды; сомасы қолмен енгізіледі.
Чекте/тақтайшада мөр басу: шағын бизнес үшін рұқсат етіледі, бірақ салыстыру бойынша нашар.

13) Комплаенс, AML/CTF және құпиялылық

AML/CTF (AUSTRAC) талаптарын сақтаңыз, транзакциялар/мандаттар, KYC деңгейлері PSP-де сақталады.
PSP, Velocity-ережелер, аномалиялар мониторингі деңгейінде санкциялық/фрод-скринингті қолданыңыз.
PayID деректерін барынша азайту қағидаттары бойынша өңдеңіз; UX және аудит үшін қажет нәрселерді ғана көрсетіңіз.

14) high-risk ерекшеліктері (iGaming қоса алғанда)

Австралиядағы банктер/PSP жеке тәуекел саясаты бойынша жекелеген санаттарды шектей алады.
Төмендетілген лимиттерді, күшейтілген KYC және қосымша транзакция талдауын күтіңіз.
Депозиттер/төлемдер үшін баламалы рельстерді және нақты қайтару процесін жоспарлаңыз.

15) «NPP/PayID Gateway» сервисінің архитектурасы

API: `createPaymentIntent`, `generateDynamicQR`, `requestToPay`, `createPayToMandate`, `refund`, `reconcile`, `webhook`.
Сенімділік: экспонент бойынша ретрациялар, демпотенттілік, оқиғалардың дедупликациясы.
Observability: метрика (табыс/істен шығу/жасырындылық), трассировка, SLA банктер бойынша алерта.
Қауіпсіздік: HMAC қолтаңбасы веб-хук, allowlist IP, құпияларды ротациялау, аудит журналы.
Деректер: банктер/арналар бойынша лимиттердің жекелеген анықтамалықтары, PayTo-мандаттардың мәртебелері, UTR-карта.

16) Өнiмге шығарудың чек-парағы

1. Банктен/PSP-тен Merchant PayID (немесе PayID пулын) алыңыз.
2. Ағынды таңдау: динамикалық QR/deeplink, Request-to-Pay және/немесе PayTo.
3. Веб-хактерді, теңсіздікті және мандаттар кестесін іске асыру.
4. UTR-бағытталған recon (daily + full), рассинхрондар бойынша алерталарды қосу.
5. Refund-flow (толық/ішінара), ODR журналдарын іске қосу.
6. PayID атауы, түсінікті қателер арқылы UX шегі экрандарын қосу.
7. SLA мониторингін және провайдерлік дашбордтарды баптау.
8. Әртүрлі эмитент банктермен және PayTo сценарийлерімен end-to-end тесттер жүргізу.

Түйіндеме

Бір реттік төлемдер үшін бай метадеректері бар динамикалық QR/deeplink ставкасын жасаңыз.
Жазылымдар мен тұрақты төлемдер үшін мөлдір UX басқару PayTo-мандаттарын пайдаланыңыз.
Лимиттерді қатал кодтамаңыз: банктер/PSP бойынша қатаңдықтарды сақтаңыз және жаңартыңыз.
SLA бойынша UTR салыстыру, егжей-тегжейлі логинг және alerting айналасында процесті жасаңыз.