Standardized method to query information we need to collect from customer and pass to gateway

[maxnet]

This has been briefly discussed in the past before, but raising it again as an issue, so that it's not forgotten.

It would be nice if each gateway implemented a method that would return the information it expects that we collect from the customer. We need to know if our webapplication should request the credit card number from the customer, or if the gateway will issue a RedirectResponse and ask for it.

E.g. gateway modules could provide that information in the form of a getSuggestedFields() method like this:

// Application needs to prompt customer for credit card, or use token
function getSuggestedFields() 
{ 
   return ['card','cardReference']; 
} 

// Application does not need to collect card details
function getSuggestedFields() 
{ 
   return []; 
} 

// Application should prompt for customer's bank (iDeal)
function getSuggestedFields() 
{ 
   return ['issuer']; 
} 

[barryvdh]

I do agree it would be nice for a standardized way to show the required + suggested parameters.

In your case, you want to automate different gateways? Otherwise just a standard documentation format would be okay probably.

[maxnet]

In your case, you want to automate different gateways?

Correct. We want to support arbitrary Omnipay gateway modules in our software, including those we have not tested.

I think its a bit odd, that one does can auto-detect what configuration a gateway module needs by calling getDefaultParameters(), but not find out something as trivial as whether or not the gateway module wants to be fed credit card information or not.

[netcelli-tux]

I have worked on a project where the application has to work with payment gateways. I achieved that by adding a Metadata interface that gets implemented by all gateways. It provides methods to return the following information:

• name: the gateway name
• description: the description that can be shown on a web application for example
• supported features: a list of flags that state what the gateway can do (recurring payment, credit card payment, push notifications, etc).
• list of parameters required to configure the gateway

[barryvdh]

Sounds interesting, is that open source / available somewhere?

[netcelli-tux]

Unfortunately it isn't but I can probably share most of it! This solution requires that all gateways implement that interface. Since it is a big effort I haven't done for all of them. I did that for PayPal, 2Checkout, Stripe and Bank Transfer. It also requires small changes in Omnipay core.

[judgej]

If this just involves adding an interface and metadata to each driver, then would it be possible to dump them all into a single PSR-4 package that extends all their namespaces and collects the code in one place? It will depend on how much is customised in the drivers, obviously. Just to give it a test drive, for science.

[aimeos]

That's also something we currently miss sadly because we want to support all methods and shop owners should be able to decide which payment methods they offer. The supported features method @netcelli-tux spoke about would also enhance the package greatly.

For client side validation, returning the type would also be useful, e.g. expiry-date is of type "date" so we don't have to hard code it in the shop. Internally, we use objects to describe the field names, their type (string, date, integer, decimal, etc.), default value if available and if it's required or optional.