PayID Australia: NPP 흐름

1) 맥락: NPP 및 PayID

NPP (New Payments Platform) -실시간 결제와 풍부한 ISO 20022 메시지가있는 호주의 국가 인스턴트 결제 인프라 (24/7/365). PayID는 NPP 위에있는 주소 지정 계층으로 BSB/계정이 아니라 전화 번호, 이메일, ABN/ACN 또는 Organization ID와 같은 "인간" 별칭으로 지불 할 수 있습니다.

• 상호 운용성: 모든 NPP 참가자는 발행 은행을 인정합니다.
• Alias 주소 지정: 지불 인은 확인 전에 PayID 이름을 봅니다 (잘못된 방향).
• 직관성과 최종 성: 판매자 계정의 크레딧이 즉시 표시됩니다. 반환-별도의 작업.
• 결제 데이터: 편리한 송금 기능이있는 ISO 20022 (결제 목적, 주문 등).

2) 회원 및 역할

NPP/스키마 라우팅 및 규칙

지불 은행 (Payer FI): 클라이언트 인증, 사기 방지, 메시지 전송.
Payee 은행/인수자 (Payee FI): 대출 수락, 알림, 보고.
PSP/핀 테크: 판매자를위한 최전선 응용 프로그램, SDK, 보고서 및 조정.
가맹점: PayID (또는 은행 정보) 를 보유하고 지불 인에게 요청/링크를 생성합니다.

3) PayID

PayID의 유형: 모바일, 이메일, ABN/ACN, 조직 ID.

• 각 PayID는 지불 인이 확인하기 전에 볼 수있는 PayID 이름과 관련이 있습니다.
• 단일 계정에는 여러 개의 PayID가있을 수 있습 은행 간 이식성은 마이그레이션 절차에 의해 지원됩니다.
• ABN/ACN-PayID는 비즈니스에 편리합니다. 회사 프로필과 쉽게 일치 할 수 있습니다.

4) 기본 결제 흐름 (NPP/PayID)

P2P (푸시): 지불 인이 수취인의 PayID → 를 입력/스캔하면 PayID 이름 → 가 → 크레딧을 즉시 확인합니다.
P2M (푸시): 판매자는 PayID를 게시하거나 미리 채워진 금액과 메타 데이터로 딥 링크/QR을 발행합니다.

지불 요청 (수집): 판매자는 지불 요청을 시작합니다. 사용자는 은행 응용 프로그램에서 확인합니

• 전자 상거래의 경우 고정 금액과 orderId가있는 딥 링크/QR을 사용하십시오.
• 오프라인의 경우 정적 PayID가 허용되지만 주문 당 동적 QR이 더 좋습니다.

5) PayTo: 전자 위임 및 자동화위원회

• 판매자/PSP는 매개 변수 (지불 자, 계정, 제한, 빈도, 설명) 가있는 티켓을 작성합니다.
• 지불 인은 은행 신청서에서 위임장을 승인합니다.
• 모든 단계의 수동 인증없이 위임 조건 내에서 추가 상각이 자동으로 수행됩니다.
• 시나리오: 구독, 유틸리티/통신, 정기 계획, 사용 기반 청구 한도.

• 다음 요금의 티켓 제한, 빈도 및 날짜를 사용자에게 표시하십시오.
• 티켓 제어판 (일시 중지/취소/업데이트) 과 웹 고리를 상태에 유지하십시오.

6) 한계 및 위험 관리

실제 제한은 지불 은행/PSP 및 위험 프로파일에 따라 다릅니다

거래당/일당: NPP/PayID의 은행 임계 값은 다양하고 다를 수 있습니다.
새로운 수신자: 시작 제한 감소 및/또는 셔터 속도가 종종 적용됩니다.
범주 정책: 개별 MCC/수직이 강화 될 수 있습니다.
PayTo 티켓: 티켓 자체에서 제한이 설정됩니다 (금액, 기간, 최대 상각).

• 하드 코드 금액을 사용하지 마십시오-한계 디렉토리를 유지하고 정기적
• 인터페이스에서 가능한 초과분에 대해 경고하고 가능한 경우 분할 검사를 제안하십시오

7) UX 및 보안

Payee와 같은 검증 확인: PayID 이름을 표시하면 수신자 오류의 위험이 줄어 듭니다.
승인 시점에 지불 인의 은행에서 2FA 및 장치 바인딩.

사기 방지/속도: 은행에는 자체 규칙이 있습니다. 가능한 "소프트" 실패를 고려하십시

투명성: UTR/시간/금액/목적 + 지원 연락처로 확인하십시오.
폴백: 딥 링크가 열리지 않으면 PayID 복사, 정적 QR 및 명령어를 제공하십시오.

8) 반품 및 분쟁

카드 의미에는 충전기가 없습니다. 반품은 원래 UTR/OrderId를 참조하여 판매자에서 지불 인으로의 새로운 신용 거래입니다.
보고서에서 부분 반품 및 전체 추적 성을 지원하십시오.
분쟁은 은행/PSP 및 지원 규정을 통해 해결됩니다. 평신도 SLA 및 증거 수집 (주문 로그, 배송, 통신).

9) 판매자 통합: 옵션

1. 정적 PayID

최소한의 개발로 빠르게 시작하십

위험: 인적 요인 (양/의견 입력), 약한 분석.

2. 동적 QR/딥 링크

주문할 생성: 고정 금액, 주문, 송금.
더 나은 주문 당 정찰, 더 적은 오류, 더 높은 변환.

3. 지불 요청

판매자의 "송장" → 지불 인의 확인.
송장, B2B 및 가변 금액 서비스에 유용합니다.

4. PayTo (e-mandents)

구독/되풀이 요금; 지불 인은 은행에서 위임장을 관리합니다.
기각 전에 동의 화면, 제한 관리, 알림이 필요합니다.

• 상태의 웹 후크 (성공/실패/보류 중), 백오프에 의한 반복 설문 조사.
• Idempotency 테이블 (orderID + 쿼리 키).
• UTR/Order년에 의한 조정/시간/금액.
• 응용 프로그램 및 ODR 절차를 환불하십시오.
• 은행/PSP SLA 모니터링 (대기 시간, 성공, 오류 코드).

10) 조정 및보고 (ISO 20022, UTR)

UTR (고유 전송 식별자) - 주 조정 키; 원래 지불과 반품을 모두 유지하십시오.
문서, 카트, 사용자 정의 Ref에 ISO 20022 할당/송금 필드를 사용하십시오.
일일 오토 레콘 및 주기적 풀 레콘 설정.
PSP 보고서: 거래, 상태, PayTo 티켓, 반품, 편차.

11) 관세 및 비용

NPP/PayID의 경우 카드 체계와 같이 고전적인 MDR은 없지만 인수에 대한 공급자 비용, PayTo 모듈, 보고, SLA 패키지가 있습니다.
지원/분쟁, 사기 방지, QR 생성 및 딥 링크 페이지 호스팅 비용을 고려하십시오.

12) 오프라인 옵션 및 QR

판매자가 제시 한 QR (동적): POS/체크 아웃에 최적; 양과 메타 데이터는 코드로 보호됩니다.

정적 QR: 금액없이 PayID를 인코딩합니다. 금액을 수동으로 입력하십시

판에 확인/인쇄: 소규모 비즈니스에는 허용되지만 조정에는 더 나쁩니다.

13) 준수, AML/CTF 및 기밀 유지

AUSTRAC (AML/CTF), 트랜잭션/티켓 로그 스토리지, PSP의 KYC 레벨을 준수합니다.
PSP 수준, Velocity 규칙, 이상 모니터링에서 제재/사기 심사를 적용하십시오.
최소화 원칙에 따른 프로세스 PayID 데이터; UX 및 감사에 필요한 것만 표시하십시오.

14) 고위험 기능 (iGaming 포함)

호주의 은행/PSP는 자체 위험 정책에 따라 개별 범주를 제한 할 수 있습니다.
한도 감소, KYC 강화 및 추가 거래 분석이 예상됩니다.
예금/상환 및 명확한 수익 프로세스를위한 대체 레일을 계획하십시오.

15) NPP/PayID 게이트웨이 서비스 아키텍처

API: 'PaymentIntent', 'GenerateDynamicQR', 'requestToPay', 'PayToMandate', '환불', '조정', '웹 후크'

신뢰성: 기하 급수적으로, dempotency, 이벤트 중복 제거.
관찰 가능성: 지표 (성공/실패/대기 시간), 추적, SLA 은행에 대한 경고.
보안: 웹 후크의 HMAC 서명, 허용리스트 IP, 비밀의 회전, 감사 로그.
데이터: 은행/채널 별 제한의 개별 디렉토리, PayTo 위임 상태, UTR 카드.

16) 출력 체크리스트

1. 은행/PSP에서 판매자 PayID (또는 PayID 풀) 를 받으십시오.
2. 동적 QR/딥 링크, 지불 요청 및/또는 PayTo와 같은 스트림을 선택하십시오.
3. 웹 후크, demotence 및 티켓 테이블을 구현하십시오.
4. UTR 지향 정찰 (일일 + 전체) 을 사용하면 잘못 정렬하여 경고합니다.
5. 환불 흐름 (전체/부분), ODR 로그를 실행하십시오.

6. UX 제한 화면, PayID 이름 미리보기, 이해할 수있는 오류 추가

7. SLA 모니터링 및 공급자 대시 보드를 설정하십시오.
8. 다른 발행 은행 및 PayTo 시나리오에서 엔드 투 엔드 테스트를 수행합니다.

요약 다시 시작

일회성 결제의 경우 풍부한 메타 데이터를 사용하여 동적 QR/딥 링크에 베팅하십시오.
구독 및 반복 지불의 경우 투명한 UX 관리 기능이있는 PayTo 티켓을 사용하십시오.
하드 코드 제한을하지 마십시오: 은행/PSP 구성 및 업데이트를 유지하십시오.
UTR 조정, SLA의 자세한 로깅 및 경고에 관한 프로세스를 구축하십시오.