Payment gatweays use different field names for similar data, and also require different sets of fields.
The payment module will need to provide a universal set of fields, a standardized list, (a schema?) which can be used to reference such fields in a common way.
It may be useful to map some fields to the same thing, for example ZipCode and PostCode have essentially the same meaning.
We should try to be exhaustive in providing field mapping options, helping to make sure all future gateways are supported. As further gateways do get added, we might find that the mapping 'schema' needs to be revised.
The related Active Merchant concept is what they call the Options Hash, which differs because there is no enforcing of field names, just a recommendation that they be common.
A draft list of fields:
id
street
name
company
address1
address2
city
state
country
zip,postcode
phone
For each gateway, we can mark which fields are required, and throw an error when they are not required.
Payment gatweays use different field names for similar data, and also require different sets of fields.
The payment module will need to provide a universal set of fields, a standardized list, (a schema?) which can be used to reference such fields in a common way.
for example:
It may be useful to map some fields to the same thing, for example ZipCode and PostCode have essentially the same meaning.
We should try to be exhaustive in providing field mapping options, helping to make sure all future gateways are supported. As further gateways do get added, we might find that the mapping 'schema' needs to be revised.
The related Active Merchant concept is what they call the Options Hash, which differs because there is no enforcing of field names, just a recommendation that they be common.
A draft list of fields:
For each gateway, we can mark which fields are required, and throw an error when they are not required.