You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just found your code and it looks exactly what I am looking for. I did notice when following your directions to save a credit card for a customer, it looked like the address info on a charge is all blank. Is saving the address info already built in, and I am just not seeing how to go about saving that as well? Or is that something that was on the roadmap to be added in later?
The text was updated successfully, but these errors were encountered:
Thanks! Part of the design philosophy behind the AuthorizeSauce library is to use Authorize.net as little as possible because their APIs are poorly conceived, poorly documented, and poorly maintained. The point of saving a credit card in their system is mainly to avoid having to prove annoying levels of PCI compliance, but that concern doesn't exist with address information.
So basically, the decision was that you can store the address information on your systems, how you want to, and have total control over it (for example, you can access it without the overhead of an API call) right alongside storing a token to reference the card info when needed.
Is there a use case or reason for needing to store the address info with Authorize.net that I missed?
I just found your code and it looks exactly what I am looking for. I did notice when following your directions to save a credit card for a customer, it looked like the address info on a charge is all blank. Is saving the address info already built in, and I am just not seeing how to go about saving that as well? Or is that something that was on the roadmap to be added in later?
The text was updated successfully, but these errors were encountered: