Re: Overhauling Payment Methods

Well, I'm just being cognizant that others may be ok using "legacy or
non-updated" enums.

But basically there are two patterns I think of to do what you want on the
top of my head:

a) Use a lot of types: Make a large type hierarchy and some of them have
properties.  So there's a CashOnDelivery type.  This is the pattern that
interactionType->Action uses for instance.  Google's systems at least will
take a "http://schema.org/LikeAction" raw string on that property and
coerce it into an object with that type (but that's not part of schema.org
itself).  But providers can also use CashOnDelivery->colorOfCash or
whatever specific properties are on that type with a full object.

b) Use a combination of enum and type: PaymentMethod now has a predicate
called methodType which has a more proper enum potentially with a large
list of values.  Types are used less aggressively and only when you want to
add properties to the subtypes.  There is only a loose relationship between
methodType and type hierarchy.  We could even potentially hack that in
Google systems to map the existing strings -> methodType which would at
least work for our systems.

I guess it depends on how many payment methods are going to exist and
whether they will more commonly need structure or not.

On Wed, Aug 7, 2024 at 8:58 AM Matthias Wiesmann <wiesmann@google.com>
wrote:

>
>
> 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
> <+41%2079%20603%2020%2035>
>
>