AbleCommerce Shopping Cart Software

This sounds like fun...
https://support.cybersource.com/cybskb/ ... t&id=C1685
I can just see the fees stacking up because people don't implement this properly in code and/or in their workflows.

Well, this is definitely concerning.

It looks as if we are at the mercy of each payment gateway and how they plan to change their API to support the different authorization types. If you look at how Cybersource is handling the change, we will need to update the Simple Order API integration to support:

Field: authIndicator
Description: Flag that specifies the purpose of the authorization. Possible values are 0 for Preauthorization and 1 for Final authorization

But in the same document, it looks as if Cybersource is not even prepared for these changes and testing is not available yet:

Integration may commence as described; however, the fields may not yet be available to test until CyberSource deploys the relevant changes per processor. The CyberSource API fields to flag each transaction will be available at various times depending on the processor. For dates on which the API fields for your processor are expected to be available, contact CyberSource Customer Support or your dedicated Technical Account Manager.

I guess there is some good news though.

What will happen to transactions that are not flagged?
Transactions not flagged as “Pre” or “Final”, will continue to be processed by your Acquirer, and will not be rejected or declined. However, based on the region and the characteristics of the authorization other fees may apply. Please contact your Acquirer to learn more about the fees

But the troubling part of all this is that AbleCommerce now supports over 100+ payment gateways and each of them will likely have to deal with the Mastercard changes in their API. With October just around the corner and little to no information or notices from the gateways, it puts us in a really bad position. The best we can hope for is that any MC transactions will still work and fees may be applicable until all the gateway integrations can be updated.

Thanks for the notice Jay. We'll make some inquiries with some of the other gateways and figure out what needs to happen.

Katie

It looks like (based on this documentation: http://apps.cybersource.com/library/doc ... _Cards.pdf) CyberSource has started to implement this. Given the time crunch we (meaning both AbleCommerce and merchants) are under with this, I was trying to figure out if I could start testing it without waiting for you to release an update. I'm not real familiar with how the XML references and class definitions work. However, when I look at the CyberSource project in the IntegratedProviders solution, it looks like I would need an updated Cybersource.Clients.dll file from AbleCommerce that includes the new field information. I guess the .wsdl and .xsd files used to create the dll would come from here:https://ics2ws.ic3.com/commerce/1.x/tra ... Processor/. Is that correct? If so, do you know when you will be able to make the updated Cybersource.Clients.dll and/or the new CyberSource source code available?

To be honest, we haven't even logged a bug report yet. We'll have to address each payment gateway separately, and this will take a considerable amount of time. As far as I know, Cybersource is the only one who is moving on this. When I checked around with some other gateways, they seemed clueless about the changes. It's odd that MasterCard they would implement this kind of change with such short notice.

Isn't the Cybersource.Clients.dll a file provided by Cybersoure? I'm pretty sure that it is, but maybe a developer will know for sure.
Do you know if they released an updated API yet?

I don't think this is going to be a simple change. We'll have to spend some time researching the issue and get back to you.

Have a great weekend!
Katie

After looking at CyberSource's site a little more, I think you are right, that DLL (or the VS project to create it) is available from them. I'll have to dig into it more next week. As I mentioned, I'm not real familiar with this stuff .

In terms of them releasing an updated API, The pdf I linked to in my earlier post today includes a section on "Final Authorization Indicator", and lists the authIndicator field in the "Request Fields" section. However, under Processors it only mentions Chase Paymentech Solutions and GPN. CyberSource has a whole list of other processors they support, though (ours is FDC Nashville Global), so I'm guessing the other processors haven't implemented it yet. They also state that you can contact CyberSource Customer Support to set the default authorization type in your CyberSource account, so I'll actually probably try that first. I'm hoping that if they set the default on the account, I won't have to change anything in AbleCommerce. But I thought I should be prepared if there is more to it than that.

As a side note, their "Secure Acceptance" method (payment page hosted by them) documentation still doesn't mention this stuff, even though the document I linked to in the original post says there will be a configuration option to choose which authorization type you want for that.

I'll talk to CyberSource next week and follow up here if I get more useful information.

Appreciate it Jay.

Normally, when a payment gateway is making a change that will affect shopping cart applications, they send out email notices to all their customers and we hear about it pretty quick. For whatever reason, this change hasn't really gotten much attention.

Looking forward to your update.

Well, so far CyberSources answer is basically "we're still working on it with the processors, we'll have more info for you eventually".

Thanks for the update Jay.

Fortunately, it doesn't look like any of the payment processors will "break" with this change from MC, but if new fees will be imposed, then I'd imagine that customers using these gateways will start complaining and companies like Cybersource will be more inclined to work on it faster.

Katie

Still no more info from CyberSource, but I dug into their documentation and API SDKs today and came up with the following (Using GOLD R12 SR1, Visual Studio Professional 2013 on Windows 7 SP1 64-bit, IIS on Windows Server 2008 R2 64-bit):

Download cybersource-sdk-dotnet-1.1.0.zip from here: http://www.cybersource.com/developers/i ... t_library/
Unzip
Open CyberSource.sln in VS 2013
Go to Build > Configuration Manager
For CyberSourceClients project, change the Platform to Any CPU & click Close
Build > Rebuild solution
Copy \CyberSource\bin\CyberSource.Clients.dll to AbleCommerce site \bin folder and AbleCommerce source \lib folder
Copy \CyberSource\Client\ServiceReferences\SoapServiceReference\Resources.cs to AbleCommerce source \IntegratedProviders\CyberSource\CybersourceTransactionWS.cs (replace existing file)
Open AbleCommerce source IntegratedProviders solution.
Edit the CybersourceTransactionWS file, replacing all instances of CyberSource.Clients.SoapServiceReference with schemas.cybersource.com
Edit the CyberSourceProvider.cs file
In BuildProviderRequest_Authorize, find: And add the following right below it: In BuildProviderRequest_RecurAuthorize, find: And add the following right below it: In GetSendDebugData, find: And add the following inside the braces: Rebuild the CyberSource project
Open the AbleCommerce source CommerceBuilder solution
Rebuild solution
Copy new .dlls to AbleCommerce site \bin folder

This works, in the sense the the transactions are accepted and processed (on the CyberSource test server, haven't tried the live server yet), but there's no visible proof when I log into our CyberSource account that the authIndicator field was included in the request. I'm not holding my breath that there will be any visible proof any time soon .

Thanks a lot Jay for taking the time to post this. I am still waiting for any of our integration partners to mention the new MC requirements.

I've read through the CyberSource document several times, and I think I've come away with a different understanding each time . I just read through it again, and I THINK that for the US region, if this new parameter is undefined (not included in the request), there is no fee. However, there would be a fee if that undefined authorization is not captured or reversed within 7 days. If this is the correct interpretation, maybe that's why it doesn't seem to be getting much attention, because most transactions are either sales(authorized and captured at the same time), or authorized separately but captured within that time frame.
The way I understand the rest of it: Including the new parameter and setting it to pre-authorization gives you 30 days to capture or reverse it before a fee is charged. Including the new parameter and setting it to final will result in a fee if the transaction doesn't actually meet their requirements for a final transaction. In all cases, you must reverse an authorization you are not going to capture; if you just let it "time out" on its own, they will charge a fee.
But I'm not a lawyer or a MasterCard employee, so I may be wrong .

I'm concerned by this sentence...

Authorization may no longer be cancelled after it is approved in full, except where there is a
system failure.

My takeaway from that is they're effectively saying you're going to guarantee the card processor a transaction fee. You basically have no choice but to capture the authorization or be in conflict with the pre-authorization rules which would result in a totally different fee.

Either way, you get hit with a fee....am I reading that right??

I'm not sure what they mean by cancelled, because it also says

Authorizations that are not captured should be reversed; otherwise a new processing integrity fee will be applied to the transaction.

To me, having both of those sentences implies that cancelled is something different than reversed.