SIM questions

[noahs]

1. I don't want to handle PANs ever, because handling PANs means PCI compliance burdens.

2. I want people to pay invoices online, and I want to make it hard (ideally impossible, but hard is sufficient) for them to somehow pay the same invoice twice.

3. I don't want to display paid invoices as something they can pay (that is, I want the website to know they paid).

It looks like SIM ticks off item 1 by its nature, and it looks like the other Authorize.net options involve handling PANs.

Unless I've missed it, I'm not seeing any transaction reporting behavior in SIM, or the ability to poll Authorize.net for a transaction status.  The closest thing appears to be subervting Relay Response custom receipt generation to hook updating the paid/not-paid status of the invoice on my website onto the receipt generation.  It isn't ideal to couple receipt generation behavior to payment success/failure reporting behavior, but as far as I can see that is the only way unless I'm missing something.  Is that accurate?

I've not had a chance to poke it with a stick yet, but with the transaction fp sequence, is there a uniqueness requirement for this that I'm missing?  Would violating the uniqueness result in a failed transaction?  i.e. if I submit the key for the invoice as the sequence number, would that cause any later transactions with that squence number to be invalid?  Is there another field to generate that sort of behavior?

[Trevor]

You are correct that the reporting for SIM is tied directly to the generation of the receipt through relay response. This is not an oversight, but something that is done by design. Tying these two things together is the most reliable way to ensure that what the customer sees always matches what shows in your database. This also allows you to provide data such as a confirmation number right on the receipt page if it is applicable to your business logic. The last thing that you would want would be to have Authorize.Net display a receipt indicating that the transaction was successful, but to have the customer not receive their order because the transaction was never logged in your system.

In regards to the sequence number, there is no particular pattern or uniqueness requirement for this field. The purpose of the field is only to add entropy to the fingerprint hash generation, so it is recommended to use random number generation.