Provide abstraction for supporting Cybersource's merchant defined data fields

[toppa]

lets discuss this

[nicholaides]

To get us started, I think we should be able to do something like this in a controller

cybersource_form.merchant_data = { some: 'hash' }
cybersource_form.merchant_data[:other_key] = value

And when we render the fields and signature, the merchant_data1 through merchant_data4 fields should contain the serialized version of the cybersource.merchant_data

Since there are limits on the merchant_dataX fields, I suggest we break the serialized data up if necessary.

For example, if the data is 300 characters, the first 100 can go in merchant_data1, the next 100 in merchant_data2, etc.

On a cybersoure response, the data should be available in a similar way to how it was set. For instance, I could access the data like this in a controller action:

cybersource_response.data # => { 'some' => 'hash' }

Also, it should error if you try to put too much data in it.

By default, it should serialize to JSON. Other options could be available (YAML, Base64, etc), or perhaps it should be customizable with any object that responds to #load and #dump. ActiveRecord provides similar functionality.

[dmcclory]

what kinds of data are we imagining using in this?

One use case that crossed my mind yesterday was allowing the browser to add information to this object. JSON serializing would work fine, we'd need to have make some kind of object/function available which could do the same serialize -> splitting across the fields.

But to do that we would need to see if it is feasible to always send the merchant_secure_data 1, ... 100 in the list of fields when signing, and whether it's acceptable to send empty field, because you wouldn't know at the time of the signing how many you might need.

It still might be worth it, to make it easier to collect user input. In our app, the only piece of information we put in a merchant_secure_data field is supplied in the browser. (a password field whose value is copied over to merchant_secure_data1 via jqeury)

[nicholaides]

For @toppa's app, they wanted to send a long URL through. It was too long for 1 merchant_secure_data field, so they ended up storing it in the database. That's the reason we were talking about a generic way for adding data that didn't require the developer to care about the size of the data (as much).

I agree, that we'd need a way for the JS to access/modify the data in the same way.

But to do that we would need to see if it is feasible to always send the merchant_secure_data 1, ... 100 in the list of fields when signing, and whether it's acceptable to send empty field, because you wouldn't know at the time of the signing how many you might need.

Agreed.

It still might be worth it, to make it easier to collect user input. In our app, the only piece of information we put in a merchant_secure_data field is supplied in the browser. (a password field whose value is copied over to merchant_secure_data1 via jqeury)

For a first version, we can omit this functionality, and let the developer use the merchant_secure_data fields as is.

[toppa]

This is done. See here and here.

An interesting issue I ran into is that Cybersource has an undocumented 700 character limit on the signed_field_names field. If you include a bunch of merchant data fields in the signed fields, you get a cryptic 500 error from cybersource (I hit it at 23 merchant data fields). It took some trial and error to figure out the problem. I thought it might have been the total data in the submission, but it seems to specifically be the signed_field_names field (as I didn't have a problem when I submitted them as unsigned fields).