Our clients had a need to display specific return values from the Cybersource call in a report, however none of the information is recorded when the payment receipt entry is added to the database, only specific fields arbitrarily chosen.
This patch will simply stuff the entire POST value into the data section uc_payment_receipts, where it is automatically serialized, and exposed to views.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | uc_cybersource-2360847-08-pay-receipt-data.patch | 1.38 KB | raycascella |
| #1 | ubercart-cybersource-payment-receipt-post-data-2360847-01.patch | 959 bytes | raycascella |
Comments
Comment #1
raycascellaThe patch.
Comment #2
raycascellaComment #3
longwaveAre you absolutely sure the POST data contains no sensitive information that should not be logged in the database?
Comment #4
raycascellaI think it may depend on the individual configuration? Though, I just did a spot check on my test data and it appears partial credit card numbers and expiration dates are also sent back with my returns. Unsure what the PCI compliance needs are for that? I suppose I could remove the specific values involving card information.
Comment #5
tr commentedSome other Ubercart payment methods will save the response if you have credit card debugging turned on. Perhaps that should be done here, rather than always saving it whether it's needed on a site or not. But even in the case of debugging the information saved should be selective - no card numbers, no expiration date. In fact, other than transaction ID and status code (OK, declined, etc.) it's not clear to me what information you could be getting from the processor that you don't already have from the order itself (customer name, etc.).
Comment #6
raycascellaI specifically need the auth_code being sent back, which is used by the client's finance department, who do not actually access the Drupal site, but are given reports pulled from it. I thought about explicitly adding auth_code to the values being saved, but after seeing how much other data is returned, my rationale for saving the full POST was if any of it was ever needed, or some new configuration sends something new, it would be instantly available, no further updates needed. Though, it seems to be alittle too much info is sent back.
Comment #7
raycascellaI've re-rolled the patch to remove any required data, returned by the POST with the 'req_' prefix. This removes all of the sensitive data, but keeps any status returns, and all other information returned by the processor, specific to that order on the gateway side, that may be needed later. There's alot of data that comes back that could be useful, but at the moment is not retained, unless explicitly done so.
It fits our needs, but feels alittle kludgy and not very open source friendly. I could also create an alter that sends the data array out for processing before it's sent to uc_payment_enter, or in uc_payment_enter itself , and default it to a NULL?
Comment #8
raycascellaOops. Reroll after fixing logic check. It was actually doing the exact opposite and ONLY keeping the sensitive info. Late night coding FTW! =-D
Comment #9
djdevinIf any data is being returned from an offsite method like Cybersource/Authorize.net it should be considered insensitive, so the entire $_POST in this case can be stored.
Any sensitive data POSTed back to us would defeat the point of using an offsite gateway since that falls under PCI storage rules even if it's temporary. The full name, last 4, and expiration are not considered sensitive data so you can store them.
Should we move this to https://www.drupal.org/project/uc_secure_acceptance_wm, as the version of Cybersource in Ubercart no longer works?
Comment #10
tr commentedThis will not be fixed in 6.x-2.x because Drupal 6 is now obsolete.
FYI, if you're using Cybersource:
We are proposing to remove uc_cybersource from core Ubercart in Drupal 8. Please post in #2641764: Remove uc_cybersource from Ubercart core in D8 if you have something to say about this.