The arb api doc requires a credit card number for new arb subscriptions.
See http://www.authorize.net/support/ARB_guide.pdf pg 10, CreditCard xml
element. BUT, the online merchant interface transaction detail screen on
the web site enables an ARB Sub...
Hi, The Auth.Net Transaction Details API doc on pg 26 lists lots of
possible statuses for a transaction. Q: Once a transaction reaches the
"settledSuccessfully" status, can it ever be changed back to something
else? If a customer disputes a charge, i...
Hi, My site does subscription billing of changing amounts. So my plan is
to have my credit card page receive the credit card / PAN info, then
store it to CIM. But even though the PAN data will never be stored on my
system (including log files, etc) i...
I just re-read your post. The PCI rules haven't changed. If the card
data is POSTed from the customer's browser to your server then your
server is in scope for PCI. How much attention your server and your
situation gets from the PCI people depends mo...
Yes, there is now an option in the CIM api that enables you to have the
PAN (card data) sent directly from your customer's web browser to the
Authorize.net system. This means that the card data never enters your
own server (not even for a millisecond...
ps. From a PCI point of view, it is best not to store the expiration
date as an expiration date, per se. Instead, think of it as a "send
email reminder date" Eg. if the exp date is 10/2012, then the last day
the card can be used is 10/31/2012. But of...
There are three parties involved in what you describe:1) The Sellers2)
The end customers3) You, the market place owner. Who is handling the
transaction between the sellers and the end customers? Are the sellers
doing it themselves, or do you want to ...