Question

I’m working on a payment library that will allow me to implement any payment processor through the same interface. The issue I have now is that I would like to improve the way the data that is feed to the processors. Right now it’s an array and I’m not happy with that array. The issue is is if you don’t know all fields in advance you’ll end up with notices or the processor code itself will need a hell of checks. The idea is to be able to take any kind of data structure because it differs between applications and make it work with the processors but also to ensure the processors get the data feed they need.

My idea now is to change that to an object. The object will come with a limited set of fields all processors require and have usually in common but the object could be extended to take additional fields.

The advantage of that would be that I can validate in the processor that it gets a payment object passed and it could validate if it implements all required fields, if not throw an exception.

So the question is now if this is a good approach or is there any better and fail save way to make sure all processors can rely on the passed data?

Answer 1

In your case, I might use an architecture similar to the following:

Class payment_data -> This class would have all common fields and likely provide some common data validation, you could also subclass this with specific processor-specific implementation where certain processors can accept additional data for processor-specific logic. There would be no need to even pass this object to the payment processing logic if it was not able to be successfully constructed according to your validation rules.

Interface payment_processor -> This interface would define common methods that any of your processor-specific implementing classes would need to be able to handle the base payment_data object.

Processor-specific classes implementing payment_processor -> These classes would all be able to handle a basic payment_data object, but might optionally be able to be passed a processor-specific subclass of payment_data that implements additional features for that processor.