Re: Overhauling Payment Methods

On Wed, Aug 7, 2024 at 1:54 PM Ryan Levering <rrlevering@google.com> wrote:

> Generally I've been trying to move away from enums-as-types in schema.org
> over time.  It makes it hard in a lot of systems (language bindings,
> coercion systems) that assume that enums are not objects.  And if you use
> the schema strictly (only allow objects with certain types as defined by
> the predicate range) enum as a type doesn't have any meaning anymore.  The
> type of the target object is already an enum defined by the class hierarchy.
>
> I haven't looked at PaymentMethod/PaymentCard before but it's an
> ontological mess in my opinion.  Having something that is supposed to be an
> actual enum (a predicate with a psuedo-fixed range of values, either
> defined in schema.org or not) with a subtype that is a type seems like a
> really poor design decision.
>
> However, if I just read your email and remove any mention of Enum, then it
> sounds more reasonable.
>

Would it make sense to have some predefined objects in schema.org for
constant values like Cash on Delivery?

My suggestion is to remove that being a "schema.org enum".  It can still be
> a PaymentMethod with a goodrelations URL to define its meaning (or the URL
> can represent a remote object in a less strict interpretation than Google
> uses).
>

I would rather have these URL point to some schema.org location, as I'm
really not confident the good relations site will be around for long, we
can recognise the urls of course.



>
> On Wed, Aug 7, 2024 at 6:16 AM Matthias Wiesmann <wiesmann@google.com>
> wrote:
>
>> Yes,
>>
>> This is what SEPA is, the ability to transfer funds using IBANs with
>> defined costs.
>>
>> Cheers
>>
>> Matthias
>>
>>
>>
>>
>> On Tue, Aug 6, 2024 at 6:11 PM Hugh Paterson III <sil.linguist@gmail.com>
>> wrote:
>>
>>> 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 <079%20603%2020%2035>
>>>>
>>>>
>>
>> --
>>
>> Matthias‬ wiesmann@google.com | +41 79 603 20 35
>> <+41%2079%20603%2020%2035>
>>
>>

-- 

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