steveoliver / commerce_vantiv Goto Github PK

From the docs:

The expDate element is a child of the card, token, paypage elements, which specifies the expiration date of the card and is required for card-not-present transactions. Although the schema defines the expDate element as an optional child of the card, token and paypage elements, you must submit a value for card-not-present transactions. You should submit whatever expiration date you have on file, regardless of whether or not it is expired/stale. We recommend all merchant with recurring and/or installment payments participate in the Account Updater program.

User and admin messages should be configurable via Drupal -- see https://github.com/steveoliver/commerce_vantiv/blob/8.x-1.x/js/commerce_vantiv.eprotect.js#L54 for example.

Vantiv should be able to allow for multiple partial authorization captures (via the 'partial' => 'true' attribute on the XML request) (see Vantiv_LitleXML_Reference_Guide_XML9.9_V1.18.pdf section 3.3.7) -- but it doesn't work. Partial captures should not result in automatic authorization reversals for the unused authorization balance, but they do. Contact Vantiv support and see what's up.

Vantiv requires, during certification at least, for follow-up payment transactions to use order ids with an alphabetical character appended to the order id. Currently we use authorizedTime as a unique value for each follow-up transaction. For example, if the first transaction for an order payment authorization is '1', the next transaction, for example, a capture, should be '1A', and any following transactions should use order id '1B', '1C', etc.

Live and test (Vantiv calls it "pre-live") modes should determine the debug options / ports / urls of different parts of the system. See https://github.com/steveoliver/commerce_vantiv/blob/8.x-1.x/js/commerce_vantiv.eprotect.js#L69 for example.