Draft request: Ability to extend a payment providers Meta Data without having to override the payment provider

[NikRimington]

Opening to track a discussion being had on slack

When implementing a site, people might be wanting to use a standard payment provider but capture different bits of transactional meta data. At the minute the only way to do this is override the payment provider(s) you want to be able to use and override the TransactionMetaDataDefinitions property. This is overkill if "all" you want to do is capture a few bits of extra information that aren't specifically required for the payment provider but are transactional.

Proposed solution is to introduce the ability to add custom meta config files:

Example format:

{
   "keepDefaults": true,
   "additionalMeta":[
       {
          "alias": "myReferenceField",
           "displayName": "My Reference Field"}
   ]
}

Naming convention for files could be: {providerAlias}.meta.config

Would probably want a mechanism of caching this so it's not reading the file all the time (I don't know how Vendr loads the payment providers when they are needed)

[mattbrailsford]

Really like this solution as it's very close to what we are already doing with the order editor config for additional info, so maybe we introduce more config files like this to allow more customization.

I think there is also scope to extend the order editor to have a better concept of a "shipment" so that we can have additional information in a specific shipment info dialog too.

[NikRimington]

Off this this, a slight question on how the transaction meta properties are store... what happens if you have 2 payment methods for the same provider.. e.g. One off Stripe payment, and Reoccuring Stripe Payment. From our discussion you mentioned that transactional meta data is stored as order properties, does it append the payment provider alias and the payment method alias to the property on the order?

Also, could the same concept as discussed here be used to extend Payment methods as the additional transactional stuff may be payment method specific as opposed to payment provider specific? (sorry brain going into a bit of a rabbit hole now)

[mattbrailsford]

Hey @NikRimington it doesn't append or prepend anything so it's up to the payment provider dev to ensure uniqueness of property aliases. Usually this is enough to prefix the variables with like stripeSomeVar. For the way payment providers currently work, this isn't an issue as most of these providers are writing meta data as part of the checkout process so they don't often back out and need resetting but that is an interesting thought.

We do have the concept of an transaction needing to be "initialized" before it is processed, so maybe we should expose something on the payment providers that can be called so that they can reset any properties they know belong to their provider "just in case".

I'll have to think of the later point, but I don't see why not 🤔 The trickier thing there might be how we reset those properties. Maybe we would have to parse the config files as part of this "Initialize Transaction" routine and assume any defined properties should also be reset.