Overhauling Payment Methods

Hi everyone,

A few weeks ago, I opened issue 3537
<https://github.com/schemaorg/schemaorg/issues/3537> as I think that the
payment method representation is currently not usable and needs a serious
overhaul.

I would like to explain why, and discuss what can be done to fix it.
Currently, the acceptedPaymentMethod field of an Organization or an Offer
takes a PaymentMethod object, so far, so good.

PaymentMethod is defined as an enum, with canonical values defined in the
http://purl.org/goodrelations/v1# prefix which points to the Good relations
page. Maintaining an exhaustive list of payment methods used in the world
is a formidable task, our systems know of 80+, and we only started looking
into this.

The Good relations page has not been updated since 2011, and the set of
payment methods it has is very limited and very western centric. Even if
you consider the different types of payment, the list is incomplete: for
instance it is missing a way to express InStoreCash for online purchases, a
common mechanism in Asia.

I would like to decouple two notions:

   - The payment method type (credit card, online service).
   - A particular payment method provider (Carte Bleue, Twint).

Now the payment / credit card types are expressed with an object hierarchy,
so the most compatible way to fix this is to add subclasses for the other
payment types which can have multiple providers.

PaymentMethod itself would remain an Enum, but with only generic values,
defined in the schema.org namespace, i.e.

   - ByBankTransferInAdvance
   - ByInvoice
   - Cash
   - COD
   - DirectDebit
   - CashOnDelivery
   - InStorePayment
   - Carrier (phone)

With maybe some additional values like SEPA bank transfer.

PaymentMethod would have the following subclasses:

   - PaymentCard
      -  CreditCard
   - *PaymentService (new)*
      - *InstallementService (new)*

PaymentService could inherit from FinancialService.

What do you think?

Cheers

Matthias

Matthias‬ wiesmann@google.com | +41 79 603 20 35