search

ConsumerDataStandardsAustralia / standards-maintenance

This repository houses the interactions, consultations and work management to support the maintenance of baselined components of the Consumer Data Right API Standards and Information Security profile.
41 stars 9 forks source link

Define new toUType value to relevant schemas #536

Closed PayPalAustralia closed 12 months ago

PayPalAustralia commented 1 year ago

Description

PayPal Australia Pty Limited (PayPal) is a limited Authorised Deposit-Taking Institution with authority to provide purchase payment facilities. Its primary business is as a digital wallet provider that allows buyers and sellers to send and receive payments online. PayPal customers are able to store balance in their PayPal account and withdraw those funds to a linked bank account, pay for goods and services or make person to person transactions within PayPal’s closed network using their PayPal account. There are three (3) types of accounts offered by PayPal: a Personal Account, a Premier Account (no longer available to new customers) and a Business Account.

As previously set out in the change request that PayPal raised in July 2021 (Define new Payee Type Digital Wallet Payee Type to relevant schemas #396) (“Change Request 396”), PayPal does not offer traditional banking products and its business and operational models are different to that of a traditional bank. Change Request 396 established a new Payee schema type of “DIGITAL_WALLET” and a payeeUType of digitalWallet, which will become mandatory on 31 August 2022. The scope of Change Request 396 did not address the ‘toUType’ field within the BankingScheduledPaymentTo schema and as such PayPal is currently unable to return information about the payee of a scheduled payment.

It is also worth noting that unlike a traditional bank, scheduled payments on a Digital Wallet do not need to be made to a pre-registered Payee.

Area Affected

To ensure PayPal data is accurately reflected and returned in the Australian Consumer Data Right ecosystem, we are recommending the following changes be made to the BankingScheduledPaymentTo schema, which is utilised by the following APIs: • Get Scheduled Payments for Account • Get Scheduled Payments Bulk • Get Scheduled Payments by Specific Accounts API

BankingScheduledPaymentTo schema (https://consumerdatastandardsaustralia.github.io/standards/#tocSbankingscheduledpaymentto) BankingScheduledPayment --> BankingScheduledPaymentSet --> BankingScheduledPaymentTo --> toUType

Current Enum Values for BankingScheduledPaymentTo.toUType:

   accountId
   PayPal cannot utilise this value, as Scheduled Payments are not to accounts owned by the consumer, and hence are not accessible under the current consent.

   biller
   PayPal cannot utilise this value, as we do not support any payments (including Scheduled Payments) to a BPAY biller. 

   domestic
   PayPal cannot utilise this value, as we do not support Scheduled Payments to a domestic bank account. 

   international
   PayPal cannot utilise this value, as we do not support Scheduled Payments to an international bank account 

   payeeId
   PayPal cannot utilise this value.  As noted above, the recipient of Scheduled Payments is not a pre-registered payee that would be included in the Payee scope.

Change Proposed

To ensure PayPal can comply with the regulatory mandates, we would like to put forth the following two changes to the BankingScheduledPaymentTo API response schema:

Change#1 Add a new Enumerated Value to the toUType field in the BankingScheduledPaymentTo response schema. PayPal recommends this value to be: Property: toUType Value: digitalWalletPayee

Change#2 To support the addition of the new toUType Enumerated Value referenced in Change #1, there are two options that PayPal would support. Of the two options, PayPal recommends Option 1. Option 1: To support the new Enumerated value described in the Change #1, add a new Properties field in the BankingScheduledPaymentsTo response schema to reference the BankingDigitalWalletPayee schema created with Change Request #396. PayPal recommends this field to be: Name: digitalWalletPayee Type: schema BankingDigitalWalletPayee (existing payeeUType https://consumerdatastandardsaustralia.github.io/standards/#tocSbankingdigitalwalletpayee) Required: Conditional Description: Present if toUType is set to digitalWalletPayee Option 2: To support the new Enumerated value described in the Change #1, add a new Properties field in the BankingScheduledPaymentsTo response schema. PayPal recommends this field to be: Name: digitalWalletPayee Type: ASCIIString Required: Conditional Description: Present if toUType is set to digitalWalletPayee. Represents the merchant/payee ID of the recipient of the Scheduled Payment and could be used by the ADR within the Get Payee Detail API to retrieve the payee information. It is important to note that this payee would not be automatically returned in the Get Payees API in the event that Payees are within the scope of the consent.

nils-work commented 1 year ago

For Change#1, I would suggest the toUType enum value and corresponding property name be digitalWallet to align to the related name in BankingPayeeDetailV2 (the schema name is BankingDigitalWalletPayee).

I believe Option 1 of Change#2, incorporating the full associated schema, would be better aligned to the addition of the new toUType proposed in Change#1. That approach would seem to be:

I would also suggest that this is actually only a single change to add the digitalWallet uType and its associated schema to BankingScheduledPaymentTo, but welcome any other comments or preferences.

It appears that Option#2 may be duplicating the purpose of the existing payeeId field in BankingScheduledPaymentTo, where a 'payeeId' (as an ID Permanence value) is provided for querying the Get Payee Detail endpoint.

Also to note, this appears to be the only change in the maintenance backlog related to the Scheduled Payments endpoints.

biza-io commented 1 year ago

Supporting digital wallet targets for schedule payments to align with payees makes sense. Our thoughts as to a way forward are that it probably shouldn’t be assumed that a payee is registered for a scheduled payment. That is to say that expecting the presence of payeeId may result in certain use cases not being possible.

On this basis our suggestion would be to adopt a structure similar to BankingDigitalWalletPayee (id, type, provider) with an additional uType as suggested.

perlboy commented 1 year ago

Indication was given at the last MI call this has been staged? We can find the branch here https://github.com/ConsumerDataStandardsAustralia/standards-staging/compare/maintenance/536 but we are unable to determine what branch it should be compared against?

nils-work commented 1 year ago

Hi @perlboy I believe it's this one - https://github.com/ConsumerDataStandardsAustralia/standards-staging/compare/release/1.24.0...maintenance/536

benkolera commented 1 year ago

Just noticing that we (Biza.io) forgot to submit a bit of feedback on this one:

The reuse of the BankingDigitalWalletPayee means that it is not possible to specify the name as the sender of the payment may not know the name assigned by the receivers account or the digital wallet provider. Our suggestion would be to define a specific payload for scheduled digital wallet payments which does not include name but continues to include identifier, type and provider.

Additionally, as this is the introduction of an additional uType it would appear this should increment the version number of the endpoint.

nils-work commented 1 year ago

Hi @benkolera

Incrementing the endpoint version for this change has been noted, thanks.

This change will result in version 2 of these Banking endpoints:

A Future Dated Obligation for version 2 will be proposed as Y24 #1 - 11/03/2024, with the retirement date for version 1 as Y24 #4 - 09/09/2024. If there are concerns with these dates they can be discussed in a future Maintenance Iteration.

To clarify the name field, a change to the description will be proposed, from:

The name assigned to the digital wallet by the owner of the wallet, else the display name provided by the digital wallet provider

To:

The display name of the wallet as given by the customer, else a default value defined by the data holder

This is not intended to be a change in meaning and is not considered a breaking change. It would apply to the corresponding description in the following schemas:

perlboy commented 1 year ago

Just noticed this but:

The display name of the wallet as given by the customer, else a default value defined by the data holder

The default value defined by the data holder may be null because no such data is stored or contrived on any existing platform. Take for instance email to email payments, the email is the name and participants (like the OP) use this as the reference point. Leaving this up to a data holder will make this field essentially worthless, in fact for recipient use cases it could be much worse (how about "NOT_DEFINED" for every payee listed).

DougFromPayPal commented 1 year ago

I do not agree with the suggestion to change the toUType to a generic 'digital wallet' value. The field is meant to specify the destination of the funds for the payment, hence the original PayPal recommendation of a toUType of digitalWalletPayee. If I have misread/misunderstood the author's intent, please let me know

nils-work commented 12 months ago

Hi @perlboy The digital wallet name field is intended to contain the display name as the customer may assign and see (or expect to see) in any other channel where a Payee or Payment Schedule is created. If a payee name is not assigned by a customer and other channels simply refer to the wallet identifier, repeating that value from the identifier field would be more appropriate than something unrelated.

Hi @DougFromPayPal Standards version 1.25.0 has now been published, so you can see this change in context in the BankingScheduledPaymentToV2 schema. In the hope of providing clarity; digitalWallet is the toUType/field name (a sibling of domestic, international etc.) and BankingDigitalWalletPayee is the schema defining a payee of that type.

As this change has now been published this issue will be closed, but if you have further comments upon review, please consider raising a new issue for consideration in a future iteration.

Thanks