API response change (not the JSON change)

[willief]

I am not the dev working on this but am researching for a client of ours (I'm a reseller).  They've been using auth.net for 10+ years, same coding and no changes made.  On Aug 2 around 3PM CST they started receiving back a different response than they used to receive.  Originally they would receive back a delimited string that had 70 fields.  Tuesday afternoon an extra field was thrown in at the end which "broke" their system. 

IT fixed the coding on their end to accomodate, but then they started receiving some responses back that added in an extra field somewhere in the middle as well, for a total of 72 fields.  Tech support said no changes were made but something had to have changed.  They've again updated their logic to accomodate since they mostly get back responses w/ 71 fields but sometimes 72 fields but are concerned that the responses will continue to change.

Has anyone else run into this in the last few days?  I know this is all fairly vague but what could cause extra fields to be sent back to them?  Thank you in advance.

[Lilith]

The new field at the end is expected -- we are in the process of rolling out a replacement for the MD5 Hash in transaction responses. More details will be forthcoming.

The new field they're saying they see in the middle, however, is not.

Is it possible to get examples of the transaction responses? And are they seeing any value at all in the new field?

[willief]

Hello.  Here is a Word doc they made showing the fields in the string (it is not the exact verbage of the response they get, just a list of the fields that he made).  I don't have the exact message that comes back but I can try to gather.  All of the new fields are currently blank when they come back.

Original Response:

1. 1
2. |1
3. |1
4. |This transaction has been approved.
5. |07898A
6. |Y
7. |1274424396
8. |
9. |ma rvbk w/pretest   tausha
10. |39.95
11. |CC
12. |auth_capture
13. |7889869
14. |FirstName
15. |LastName
16. |
17. |123 Wayne Ave
18. |Stony Point
19. |NewYork
20. |10980
21. |USA
22. |5554294077
23. |
24. |Email
25. |
26. |
27. |
28. |
29. |
30. |
31. |
32. |
33. |
34. |
35. |
36. |
37. |
38. |F9C9243F3E55ADB348A635BF9031B612
39. |
40. |
41. |
42. |
43. |
44. |
45. |
46. |
47. |
48. |
49. |
50. |
51. |
52. |
53. |
54. |
55. |
56. |
57. |
58. |
59. |
60. |
61. |
62. |
63. |
64. |
65. |
66. |
67. |
68. |
69. |780731
70. |175

Response that has the 72 fields in it:

1. 1
2. |1
3. |1
4. |This transaction has been approved.
5. |H26536
6. |Y
7. |20098616085
8. |
9. |Completing CE courses Online  1 Online Practice Test – Insurance
10. |36.45
11. |CC
12. |auth_capture
13. |8282884
14. |First
15. |Last
16. |
17. |1234 Flagstone Ave
18. |Riverside
19. |California
20. |92503
21. |United States
22. |5552950121
23. |
24. |Email
25. |
26. |
27. |
28. |
29. |
30. |
31. |
32. |
33. |
34. |
35. |
36. |
37. |
38. |F5FA041899AC812E5BE477B3A175311D
39. |M
40. |
41. |
42. |
43. |
44. |
45. |
46. |
47. |
48. |
49. |
50. |
51. |XXXX0771
52. |MasterCard
53. |
54. |
55. |
56. |
57. |
58. |
59. |
60. |
61. |
62. |
63. |
64. |
65. |
66. |
67. |
68. |
69. |
70. |1559501
71. |601062
72. |

The response w/ just 71 lines that they get most of the time is the same as the 72 above except one of the fields between #38 and #68 are not there.

[Lilith]

Thanks. For now, please have your parser disregard the 72nd position. As I mentioned, that will be used for a new transaction response hash, for which we'll provide documentation in the near future.