Define new Digital Wallet Payee Type to relevant schemas

[AHomersham]

Description

Unlike conventional banking organisations, PayPal Australia Pty Ltd (PPAU) (and potentially other payment processing companies who will participate in the CDR regime at a later point in time), do not capture some of the consumer payee data that are specified as mandatory fields in the Consumer Data Standards. Part of PPAU’s core business is providing digital wallets for buyers and sellers to send and receive payments online. Unlike traditional Authorised Deposit-Taking Institutions (ADIs), consumer’s balances held in their digital wallet are typically linked to existing financial instruments, such as bank accounts. Consumers can withdraw their funds back to their linked financial instrument at any time or pay for goods or services or make person to person payments. PPAU’s systems and operations that facilitate the processing of online payments through digital wallets therefore differ significantly to that of a traditional ADI, such as a bank.

Typically, a bank customer creates a payee by entering payee details into their bank’s online portal prior to initiating a payment. For an individual payee, this generally includes a name, account number and BSB, or a Payee ID. For a business payee, this may include company name, address, institution account/routing number, or BPAY details etc.

At PayPal, digital wallet payment transactions are performed within a closed-loop proprietary two-sided network: from PayPal to PayPal account only. PayPal accounts do not need to be linked to a bank account.

Within the PayPal digital wallet ecosystem, to make a payment to a personal account, a customer will enter the recipient/payee’s PayPal digital wallet account ID (which is in the form of an email address). For an online purchase/contract service transaction, a PayPal customer will click on the PayPal checkout button on a merchant’s checkout page (which will automatically route the transaction to the merchant’s PayPal account).

In Australia, to set up a personal PPAU digital wallet account, a customer needs to only enter their email address and name. The customer is then prompted, but not required, to link a card and/or bank account to their digital wallet. To set up an Australian PayPal business account, a customer will need to enter business information including company name, ABN, ACN, business address, primary authorised user and address.

As a result, PPAU does not capture or store a number of sub-schema required by the existing Get Payees and Get Payee Detail API endpoints.

Note: This issue will likely be relevant to not only PayPal, but other payment processing and digital wallet businesses who are joining the CDR ecosystem.

Area Affected

Type in BankingPayee and payeeUType in BankingPayeeDetail, which are present in responses from the Get Payees and the Get Payee Detail endpoints.

Change Proposed

Type in BankingPayee

Add additional enumerated value(s) to the current list (International, Domestic, Biller) that represent a payment processor payee. PayPal recommends 2 options for the community to consider:

• Option 1 (preferred): Add a single, new BankingPayee response value to identify a payment account / digital wallet.

• Option 2: Add a single, new BankingPayee response value to identify a payment account / digital wallet, as well as an enumerated value to delineate between a personal or business payee.

payeeUType in BankingPayeeDetail

Add the additional enumerated value(s) created for BankingPayee to the current list (International, Domestic, Biller).

New Payee Response Schema

The current schemas available are BankingDomesticPayee, BankingBillerPayee, BankingInternationalPayee.

PPAU recommends the following response schema values be added, as per each of the options considered above:

Option 1
For Option 1 described under BankingPayee, add a new value:

DigitalWalletPayee

• DigitalWalletPayeeAccountID – this would represent the account ID for the Digital Wallet Payment Payee (in text format, suitable to capture an email address).
• DigitalWalletPayeeName – this would represent the full name name of the Digital Wallet Payment Payee.

Option 2
For Option 2 described under BankingPayee, add a new value as well as an enumerated value to delineate between a Personal Payee or an Organisational Payee:

DigitalWalletPayee

• Type – enumerated value (Personal, Organisation)
• DigitalWalletPayeeAccountID – this would represent the account ID for the Digital Wallet Payment Payee (in text format, suitable to capture an email address).
• DigitalWalletPayeeName – this would represent the full name of the Digital Wallet Payment Payee.

PayPal request that @CDR-API-Stream label this issue as urgent, and include it for consideration as part of the current iteration of the standards.

[CDR-API-Stream]

This issue was discussed in the 9th maintenance iteration call. Based on discussion with PayPal and the iteration call participants, the following solution is proposed for comment:

Context:

• Currently the Payee APIs do not support Digital Wallet contacts
• Extending support for digital wallet payees should seek to deliver a provider-agnostic solution
• Requirements:
  • There may be many Data Holders that off digital wallets
  • Data Holders may support one (closed wall system) or many (P2P) digital wallet providers
  • A Payees list may include one or more digital wallet provider Payee contacts
  • Defining Digital wallet providers should be extensible to support new entrants
  • A Digital wallet contact has a display name and wallet identifier
  • Identifiers may be represented by one or more defined types such as email phone, name etc.
  • Additional provider specific details may be required in future, but no immediate needs are identified to support PayPal contacts

Proposal:

• Extend BankingPayee type to include DIGITAL_WALLET
• Extend BankingPayeeDetail payeeUType to include digitalWallet
• Extend BankingPayeeDetail with new BankingDigitalWalletPayee entity:

"BankingDigitalWalletPayee": {
      "type": "object",
      "required": [
        "name",
        "identifier",
        "type",
        "provider"
      ],
      "properties": {
        "name": {
          "type": "string",
          "description": "The name assigned to the digital wallet by the owner of the wallet or the display name provided by the digital wallet provider"
        },
        "identifier": {
          "type": "string",
          "description": "The identifier of the digital wallet (dependent on type)"
        },
        "type": {
          "type": "string",
          "description": "The type of the digital wallet identifier",
          "enum": [
            "EMAIL",
            "CONTACT_NAME",
            "TELEPHONE"
          ]
        },
        "provider": {
          "type": "string",
          "description": "The provider of the digital wallet",
          "enum": [
            "PAYPAL_AU"
          ]
        }
      }
    }  

Example:

{
  "payeeId": "ID Permanence resource identifier",
  "nickname": "The nickname provided by the consumer for the contact OR a display name provided by the wallet provider. For PayPal this will be a display name e.g. 'John Smith'",
  "description": "If applicable, a description of the payee contact. For PayPal this data is not applicable",
  "type": "DIGITAL_WALLET",
  "creationDate": "If applicable, the creation date of the payee contact. For PayPal this data is not available.",
  "payeeUType": "digitalWallet",
  "digitalWallet": {
      "name": "For PayPal this will be a display name e.g. 'John Smith'",
      "identifier": "[email protected]",
      "type": "EMAIL",
      "provider": "PAYPAL_AU"
  }
}

Implementation Considerations:

• Breaking change for consumers to Get Payees v1 and Get Payee Detail v1
• Future Dated Obligation for Get Payees v2 and Get Payee Detail v2
• If the Data Holder does not offer digital wallets, the Data Holder can fully support v2 immediately (accept both v1 and v2)
• 6-month lead time would impose a FDO of 31st of March 2022. Data Holders can support v2 as early as is practical but no later than 31st of March 2022. All Data Holders must support v2 by this date.
• Does not break existing client implementations because the endpoints will be versioned. Hence Data Holders seeking to support v2 endpoints can do so as soon as practical.
• Propose retirement of v1 APIs 1 month after v2 FDO. Therefore, DHs can retire v1 any time after 31st April 2022.

Pending feedback this change will be staged for review.

[CDR-API-Stream]

These changes have been staged for review: ConsumerDataStandardsAustralia/standards-staging@release/1.15.0...maintenance/396

Based on discussion in the final maintenance iteration call and accomodating lead time for banking DHs the obligation dates have been defined as July 31st 2022 to provide additional time for implementation.

[CDR-API-Stream]

This change was incorporated into release v1.15.0. Refer to Decision 212 for further details.