Add Payment Channel and Method to Curb Events

[jiffyclub]

Explain pull request

Cities are often interested in how their curb users are paying for their time at the curb, for example the breakdown between cash, cards, mobile, etc. This adds a payment_channel and payment_method fields to the Curb Event model and includes a list of potential values for each.

The "channel" describes the medium by which a payment was made, such as at a physical meter or via a mobile app. The "method" describes how money was exchanged, such as via cash or a credit card.

Closes #157.

Is this a breaking change

• No, not breaking

Impacted Spec

Which API(s) will this pull request impact?

• Events

Additional context

I totally just made up many of the items in the suggested list of payment types, input from practitioners on changes or additions is welcome.

[hdmm3]

I wonder if it's worth distinguishing between the payment channel and the payment method. The payment channel is the medium or platform used to pay: meter, mobile app, website, sms. The payment method would be the instrument used to pay: cash, credit/debit card, transit card, prepaid account, permit, etc.

[jiffyclub]

I've split the payment_type into payment_channel and payment_method enums.

I'm not sure where the billing item should go... maybe both places?

[jacobmalleau]

I agree with what is being proposed here, definitely something CurbIQ would use.

[mplsmitch]

We will be discussing this at the Feb 25th CDS Working Group meeting. Please review and leave your comments and questions ahead of time.

[schnuerle]

Comments from working group meeting

• Matt Davis (MD) of Populus - suggestion to split the way user interacted vs how they paid for curb. PR adds payment method and payment channel with method being things like credit card or cash and channel being things like meter or mobile app.
• Mitch V - everyone go and look at PR and add any enumerables that are missing from the two fields.
• MV- are there other things we are not covering, connected vehicles bluetooth, RFID etc

[schnuerle]

Do we need a 'transaction_id' and payment_vendor_id (UUID from data source file) field as well to connect this to external payment platforms.

[rneubauer]

I second the Transaction ID for sure.

[schnuerle]

To keep this in 1.1 we are going to have to resolve the conflicts, and incorporate feedback into the PR.

[jiffyclub]

I've rebased on dev and added a payment_transaction_id field to the Event schema, and added a digital_wallet option to the payment type enum.

[schnuerle]

Hi @jiffyclub could you resolve the new conflicts with the dev branch. It's not allowing me to. There have been updates from other PRs.

[schnuerle]

We will be reviewing this at tomorrow's public Curb Working Group meeting. However we won't have much time to discuss, so leave your comments and suggestions here as general or inline comments to spark changes before the CDS 1.1 release is made.

[jiffyclub]

Rebased to fix conflicts. I don't have strong opinions on the different payment methods people are proposing so I'd like to get to something we can merge and then if people want to make edits they can make their own PRs.

[schnuerle]

@jiffyclub Can you turn on admin editing on this PR? It might be too late for that.

If so, can you make these changes based on the WG discussion?

• Add new channel value, phone for when people can call a phone number to pay via automated phone tree or talking to a person, etc.

I think that's all that came out of the discussions, but if you picked up on other things, please tweak the PR.

[jiffyclub]

I added the telephone payment type in https://github.com/openmobilityfoundation/curb-data-specification/pull/158/commits/a0f37e874f5752fd465898b071e368fcaae75ebf