If you’ve not already heard of them, Commidea are one of a number of options for payment gateway providers for ecommerce sites (the people who actually process card transactions when card details are taken online).
Commidea provide a fairly normal XML/SOAP interface to push through card transactions, but if you’ve not used them before there is a lack of good documentation publicly available about their services. In particular, their “token gateway” service is a hidden gem that even I only discovered recently…
Here at Coolbox, we have worked with them on a number of ecommerce projects, primarily because their capped pricing model is favourable for some clients like Mandarin Stone who process high-value transactions.
And a “token gateway” is… what exactly?
The Commidea token gateway service allows a developer to ‘tokenize’ a card for re-use in further later transactions. The customer’s card details are saved securely on the (PCI compliant) Commidea servers, and you can simply store a reference code to process further transactions through your account using the same card.
Why would you use one?
Any web developer with any sense runs a mile from the idea of storing any sort of card details. It’s one thing to maintain a secure server, but quite another to deal with the complexity of the PCI regulations and approval processes required. So, when card details are entered by a customer the developer has a single shot to create the transaction. The normal process would be to either take the money immediately, or simply authorise the transaction and save the authorisation details to confirm settlement later (e.g. on dispatch). The former is often known as a ‘FullAuth’, and the latter as ‘PreAuth’ then ‘PostAuth’. Pre- and then PostAuth is probably ideal for dispatchable goods but it entails risk – the PostAuth might fail (PreAuth’s usually expire after a couple of days) and then your ecommerce client is left without payment.
In addition, in real life things tend to change. After the customer completes and pays for an order, they might change their mind about what they wanted, an item they included might actually be out of stock, etc. Other payment gateway providers usually provide some sort of mechanism to refund against an existing authorised transaction without card details, but what happens if the customer actually wants to add to the order and needs to pay more? Without card details anymore, you’re stuck, and need to take further payments manually by phone, etc.
Token gateway to the rescue! For example, our current Commidea payment code processes something like:
- Gather customer details during checkout.
- Take customer card details and push through a FullAuth transaction. If payment fails, try again.
- ‘Tokenize’ card details and store this token with the order details.
- Direct customer to an order tracking page, and notify admins of order.
- If order needs to change, process further transactions using the card token (e.g. cancellation refund to card, partial refund to card if items need to me removed from order, extra payments can be taken will customer consent when modifying an order.
Subscription, anyone?
Recurring subscription payments are often handled quite effectively by payment providers, and if your subscription is regular the token gateway described here may not be the ideal solution (as you are reponsible for the “recurring” bit). However.. if your subscription is subject to change i.e. you are billing retrospectively for services provided over the past month, this ability to safely store card details is invaluable.
Show me some code!
The token gateway itself is fairly easy to use, we use PHP and communicate with the web server using SOAP. A snippet to get you pondering..
$process = array( 'MerchantDetails' => $this->getMerchantDetails($log),
'TxnType' => $log->getBalance()<0 ? '01' : '02',
// ^ purchase or refund
'CNP' => 'Y',
'ECom' => 'Y',
'TokenID' => 'some token id',
'TxnValue' => round(abs($log->getBalance()),$this->currency_exp),
);
$client = new SoapClient('token gateway WSDL');
$result = $client->ProcessTokenTransaction(array('Request'=>$process))
->ProcessTokenTransactionResult;
/* then process $result just like a normal Commidea transaction response */
Find out more
As I hinted earlier, this service from Commidea isn’t exactly well documented publically. If you like know more, or to discuss a project involving the Commidea payment gateway, please contact us.
Tags: Development, Ecommerce, PHP, SOAP