acceptedPaymentMethod per channel

[nickevansuk]

Proposer

Sportlabs / ODI

Use Case

A more fully featured definition of payment methods/requirements where we can actually indicate which methods are available, and if they are pre/post/recurring payment. I can see a scenario, for example, where a provider may only want to display offers where payment can be taken via Paypal.

Why is this not covered by existing properties?

The existing properties suggested in #98 do not allow for per-channel granular specification of payment methods.

acceptedPrepaymentMethod vs expanding availablePrepaymentChannel

We could add a new property acceptedPrepaymentMethod for payment methods available, including:

• http://purl.org/goodrelations/v1#PaymentMethodCreditCard
• http://purl.org/goodrelations/v1#PayPal
• New definitions for Stripe, etc.

However as you note @dolkensp for full accuracy we'd also need to specify these per-channel, which makes this slightly more complex.

So a redesign could look like this:

TelephonePrepayment, OnlinePrepayment and OpenBookingPrepayment could all subclass Prepayment.

  "availablePrepaymentChannel": [
      {
        "type":"TelephonePrepayment",
        "acceptedPaymentMethod": [ "http://purl.org/goodrelations/v1#PaymentMethodCreditCard" ]
      },
      {
        "type":"OnlinePrepayment",
        "acceptedPaymentMethod": [ "http://purl.org/goodrelations/v1#PayPal" ]
      },
      {
        "type":"OpenBookingPrepayment",
        "acceptedPaymentMethod": [ "http://purl.org/goodrelations/v1#Stripe" ]
      }
  ]

It's unlikely that we'd want to specify the types of acceptedPaymentMethods available on OnlinePrepayment, OpenBookingPrepayment and TelephonePrepayment on a per-Offer or per-Event basis (much more likely these are a function of the booking system #147 or organizer), even when considering memberships and direct-debit (openactive/open-booking-api#45).

It's more likely an organisational policy for acceptedPaymentMethod on each channel, for each type of purchase (e.g. PaymentMethodCreditCard over phone or online, [DirectDebit](http://purl.org/goodrelations/v1#DirectDebit] online only).

So is this actually something like availablePrepaymentMethodConfiguration at the Organization or BookingService level? Which you can specify an array of configurations (one for "Pay as you go" one for "Membership", etc, and reference them within the Offer or Event)?

Worth also factoring this into #147 and revisiting when we get to membership stuff openactive/open-booking-api#45?