Add support for Cybersource Secure Acceptance.

[ntalbott]

Issue by DarkFox
Monday May 19, 2014 at 16:38 GMT
Originally opened as https://github.com/Shopify/active_merchant/pull/1207

---

Cybersource's new integration method, which replaces their Hosted Order Page and Silent Order POST integration methods.

API documentation: http://www.cybersource.com/developers/develop/integration_methods/secure_acceptance/

---

DarkFox included the following code: https://github.com/Shopify/active_merchant/pull/1207/commits

[sshaw]

Anything I can do to help get this merged in?

[DarkFox]

Feel free. I haven't had much time due to other duties.

I expect to move our own project over to use OffsitePayments, when we upgrade ActiveMerchant in september, so I'll take a look at it then.

[sshaw]

@DarkFox so your work is complete? If so any reason it's not merged @ntalbott?

[ntalbott]

@sshaw while I helped with the extraction of offsite_payments from active_merchant, I'm not an ongoing contributor to it.

[mohamadmzannar]

Hello Sirs,

Kindly any updates on this?

We need to have a payment module for CyberSource Secure Acceptance Web/Mobile which is the hosted solution from CyberSource

http://apps.cybersource.com/library/documentation/dev_guides/Secure_Acceptance_WM/Secure_Acceptance_WM.pdf

Kindly advise.

best,

[tedgrubb]

Bump

I'm also in the process of moving to CyberSource Secure Acceptance.

Thanks!

[llopez]

Hi Guys,

I will be contributing to this during this week

[xantari]

Folks, be careful with cybersource secure acceptance. We have been using it for years and it has a host of unfixed problems that cause us a lot of phone calls. We have reported it to them over the years including the following:

1. Secure acceptance silent order post messages are valid for 30 minutes, after that they expire. However duplicate payment submission checking only works for the first 15 minutes of that 30 minutes. So if someone hits the browser back button from your receipt page at say 20 minutes and hit "Yes" to resubmit the form data to cybersource secure acceptance silent order post you will cause the customer a duplicate payment on their credit card. We have reported this to Cybersource for over 6 years now, and they still have NOT fixed this issue.

2. Some browser toolbars strip some of the HTTP Post data or do something to mess with the page and causes a failed submission to the silent order post end point. But instead of returning reason code 102 (invalid fields encountered) message with a list of invalid fields, the customer gets a Cybersource generic error page. So good luck fielding those customer service calls, as Cybersource is not returning the reason for the error back to your program. So their API symantics are inconsistent, and this causes customer service phone calls.

3. Their API is wildly inconsistent with invalid/missing data. So good luck trying to convey the actual issue to the end user. For instance In some cases an invalid zip code is returned as this:

Key: invalid_fields Value: bill_to_postal_code

This is expected behavior and is what is documented in the Cybersource SOP API manual.

However, it appears that Cybersource does not follow their own API documentation and sometimes only return the error fields in a different field:

Key: message Value: The following request field(s) is either invalid or missing: bill_zip

As you can see, the way they report errors in inconsistent. And even the field names being returned in the message are erratic.

[ghost]

Hi Xantari,

I've worked with Secure Acceptance (SA) too and can provide some advice for your above issues:

1. Transactions may be considered valid if the signed_date_time is up to 5 minutes ahead of UTC or up to 30 minutes behind. As you say the duplicate check is only in place for 15 minutes however a workaround is to set the signed_date_time to always be 15 minutes behind UTC so e.g. if it's 15:00 UTC, set the signature time to 14:45 UTC. This way the request is only valid for 15 minutes which will match the duplicate check window.

2. SA signs all custom receipt responses; if the access_key has been stripped from the request then SA cannot determine who it is from nor sign the message so a generic 4xx error is displayed. Recently an "error reference number" has been added to such error pages; if the customer gives you this then Customer Support should be able to look up internally what the issue was.

3. The difference you are seeing is that the first example failed validation in SA whereas the second failed validation in the ICS auth/bill etc. service. In your example "bill_to_postal_code" is an SA field whereas "bill_zip" is the equivalent SCMP (legacy API) fieldname. The reason this happens is that validation can vary by processor e.g. if there's a field, "field_a", processor 1 may allow up to 10 characters whilst processor 2 may allow up to 15. Since SA is only a proxy to the ICS service(s), it does not know which processor will be used so it must allow up to 15 characters to accomodate both. Unfortunately, all you can do is add client-side validation to your checkout page based strictly on what your specific processor will allow (any differences between processors for a field is documented in the SO API/SCMP documentation).

[xantari]

@MrIssueReporter Thanks for the tip for number 1.

In regards to 2., I still contend that this should NEVER happen, they should be returning response codes back to my page so that I can control the messaging to the end user. Instead the user sits at the page dumb founded, and our call centers then call us for help. We would rather the call centers not call us and allow us to handle the errors more appropriately to reduce IT support phone calls.

3.: They need a consistent API. I don't want to have to program around two completely different systems. The API from stripe.com is worlds better than SA.

[ghost]

@xantari Have you considered using their new product, Flex Microform? https://www.cybersource.com/developers/integration_methods/hosted_flex/

It works similarly to Stripe Elements or Braintree's Hosted Fields in that you render a CyberSource-hosted iframe on your page which captures and tokenises the card number giving you a token with which to perform the auth/bill on your backend server using a SOAPI/SCMP client. Alternatively you could use it with SA SOP if you want SA to handle 3DS for you.

[xantari]

@MrIssueReporter I knew about the Flex API (we are going to hopefully be switching to it soon), but this might be even easier to switch if it works similar to stripes payment form. Thanks for the info!