Showing results for 
Search instead for 
Did you mean: 

Authorize.Net as a Service

I have a series of questions with regards to Authorize.Net


1) Is AcceptCustomer a stand alone service provided by Authorize.Net to allow customers to register their data to bypass all else?


2) Is there a central point that will allow the customers to register themselves and if so, how will they identify themselves to link to us?


3) Are there any existing HTML templates that will allow us as developers to create a site to share with our customers?



My initial way of thinking is that Authorize.Net is a SDK that allows us to create user interfaces to connect a vendor with a customer and using a third party service from Authorize.Net to validate the credit card and transactions, since we do not have the ability to validate a random credit card should it be given to us.  My question is a) do we create the User Interface for the Customer or does b) a central webpage exist that we should re-direct customers to?


Finally, can someone explain what the vauge term "AcceptCustomer" means? Is this available without being set up as a vendor?


Any assistance on the above is appreciated.




Hello @aestrada 


The merchant is responsible for creating the user interface in your scenario.  We offer APIs and SDKs to help developer integrate with Authorize.Net.  Our Accept suite of tools including Accept Customer help reduce PCI DSS scope.


Accept Customer is a payment-on-file solution which we refer to as Customer Information Manager.  It uses hosted forms that merchants  reduce their PCI DSS scope while still allowing their customers to securely store payment details on Authorize.Net servers.  The alternative is to create your own UI and use our API to store payment information but with higher PCI DSS responsibility.


I hope that helps.



Administrator Administrator

I would like to understand the work flow with more detail.

1) In the "Accept Customer" UI, which essentially is a website available from GitHub, we can download it and install it on our IIS server and manage it ourselves, the .Js files have the libraries we need to validate the credit cards, as well as other useable methods should we go in that direction.

The alternative to installing the "Accept Customer" UI from GitHub is to redirect our paying customers to an available page which you guys host, with limited functionality I think.

I am trying to connect the dots, over on my side.  If our customers go to the redirected page.  How will we know that the customer has entered their Name, Address, Phone number, and simply allow them to pay.  We technically pass a pre-generated token - as I am led to believe that pre-generated token only holds information for us "The Seller", when we pass that token and the customer enters his/her payment information should we use the Hosted form, do we have the ability to add detail lines such quantity, description, cost, taxes?  How are those fields created using the Hosted form?


After the Customer clicks on "Pay" on the Hosted form, I assume the data is submitted to a Hosted location.  Do we as Sellers typically log in using a certain "Method" and pull the Orders that have been made?  If yes, can you give us the MethodName to call?  Finally, once the customer clicks "Pay" is there any returned fields that we can capture using our local forms?




I am also curious is it absolute that a "Customer Profile" be created by the "Seller"?  


I am being told the system is similar to PayPal, do customers need to log-in or is the token to recognize them?  The confusing part is what purpose does the "Customer Profile" serve the Seller.


Thanks for helping shed any light on this.


To chime in briefly,

You can build your UI however you want. You can hand code from scratch or get any template you can find. There are minimum requirements to use the profile, such as each customer must have a unique Id. At some point I will be doing this for one or more clients. The benefit to the seller is that it makes it easy for customers to return and shop at your store as many times as they want, without having to start from scratch filling out their billing details. You accomplish this without incurring any extra large expenses related to PCI compliance, because the sensitive information is all handled by authorize.

There are numerous ways for you to get transaction results. My personal favorite is using webhooks. Authorize will communicate the results to your server, usually within 3 seconds of when the transaction is successfully completed. I’ll try not to write you a novel, but the gist of it is that keeping credit card data secure is very very expensive for smaller sized merchants. There are requirements you have to satisfy that are prohibitively expensive unless you have a huge amount of space to spread the overhead.

So authorize will offer products such as this, where the credit card data and what is called the cardholder data environment are entirely on their server. It frees you up of costs. The catch is that you will have to implement some programming so that your server can communicate with authorizes server. I’ll chime in again later, my noodles just got done.

Hi @aestrada 


Do checkout our recorded Webinar on Accept Suite and its various use cases .




Send feedback at