Re: Overhauling Payment Methods

Coming from a USA/Europe perspective one issue encountered is on which
system people are able to accept payments.  For example, Europe has IBAN
and a USA bank account often can’t transfer funds directly. So even within
a value related to bank transfers there are different financial systems and
these should be able to be exposed for machines and  end-users.

All the best,
-Hugh

Sent from my iPhone


On Mon, Aug 5, 2024 at 8:49 AM Matthias Wiesmann <wiesmann@google.com>
wrote:

> 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
>
>