Re: Overhauling Payment Methods

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