Aller directement à la fin des métadonnées
Aller au début des métadonnées

Omnipay is an open source PHP project designed to help e-commerce coders deal with the different APIs that commercial payment processors provide to their systems. The code claims to work directly with the remote systems rather than relying on published PHP apis.

It is not a standalone pieces of software, but a library. It doesn't try to encapsulate the payment processors entirely, but instead provides helper functions that hide some of the messy bits.

It only works with credit card payments.

It supports quite a lot of payment processors.

It doesn't try to do recurring payments managed by the processor, but does support 'token-based' recurring payments.

 

So it's potential for helping CiviCRM is as:

  1. To include as a library (i.e. in the packages directory)
  2. To be used within the code of the payment processors (i.e. the CRM/Core/Payment files).

Eileen has already demonstrated it's usefulness by writing an extension that provides contributed payment processors using the library.

 

But also, it's useful for helping us refactoring our existing code. By providing proven abstractions of payment processors, we can recycle them and (optimistically) in the process make the implementation of new omnipay-supported processors "automatic" (in theory).

So here are some ideas from the omipay code:

  1. The credit card object. This encapsulates a visitor's credit card information (e.g. their name + card number + ccv + other stuff, maybe). CiviCRM currently has these fields hard coded (with a different set of fields for direct debit processing). By using a credit card object (or rather, a payment instrument object), we can allow the payment processor to alter those fields as it needs (is this true?). This cleans up the existing mess with direct debit, and allows us to use swipe devices for credit card processing, for example.
  2. The gateway object. This encapsulates the specifics of the payment processor interface, including things like the user/passwd of the merchant. This is trickier since it gets stored in the payment processor table and is already handled to some extent with CiviCRM, but this looks like a more flexible model. Any fields that aren't already in the payment processor table would have to get stuffed into some "extras" blob field, which wouldn't be beautiful, but perhaps this should be considered from a security point of view as well (an existing discussion (where?)).
  3. Onsite vs. offsite. CiviCRM classifies payment processors using a billing mode switch which makes for ugly and hard-to-verify code. Omnipay just requires/allows payment processors to define a bunch of methods and the d is that they don't have to implement all the methods. So on-site gateways do not need to implement the completeAuthorize and completePurchase. Then the core code flow is controlled by whether the payment processor implements the method.
  4. Authorization. The Omnipay methods accept an options array that may include credit card objects and/or tokens, so core could use this model to build-in support for recurring contributions.

I notice that Eileen may already have given us a head start in this direction with her extended payment object in her omnipay extension.

Étiquette
  • Aucun