Test Opaque Token

Status: Under Review
by on ‎02-15-2017 12:55 PM

It would be great if there was a test token that could be used to test the server side code that transmits the AcceptJs token to the Gateway, similiar to the way one uses test credit card numbers.

Status: Under Review
on ‎06-01-2017 06:33 PM

Agreed. I'm writing tests for my code and it would be so much easier if I could have some set tokens that always works or fails. An API call to generate a test token would work too. Stripe has this and it's awesome.

on ‎06-15-2017 12:02 AM

Yes, it will be very useful for unit tests, because in other case I cannot write tests for my method, which creates customers in your service. In fact I cannot write tests for the whole my service, which works with your SDK, because all actions with recurring billing require payment info, but in my case this info can be created only via opaque tokens.

on ‎06-15-2017 10:42 AM

If you step through the Accept.js script and what it calls, you'll eventually run into the API method that's called to generaten the token/nonce. If you call that API method yourself, you can get tokens returned independent of Accept.js, which would then enable your test processing.


It's not officially documented, so I can't promise it will always work, but at least for now that's an option. I detailed more info including the actual API method in this thread.


We'll continue to look at ways to best serve your needs here, perhaps by documenting and supporting the current API method used, or providing a test token.

by Administrator Administrator
on ‎06-15-2017 02:33 PM
Status changed to: Under Review
on ‎07-23-2017 07:24 PM



We are in the process of supporting the Authorize.net API in addition to Stripe and having a supported way to generate opaque test tokens would be a huge benefit to the effort.

‎08-19-2017 02:11 AM - edited ‎08-19-2017 02:22 AM
 How to easily get your server side tokens,  no Javascript required ...

 Getting a token generated from your server is easy. Below is a very basic example in Go:

package main

import (

var err error
type error interface {
	Error() string

func newUUID() (string, error) {
	uuid := make([]byte, 16)
	n, err := io.ReadFull(rand.Reader, uuid)
	if n != len(uuid) || err != nil {
		return "", err
	// variant bits
	uuid[8] = uuid[8]&^0xc0 | 0x80
	// version 4 (pseudo-random)
	uuid[6] = uuid[6]&^0xf0 | 0x40
	return fmt.Sprintf("%x-%x-%x-%x-%x", uuid[0:4], uuid[4:6], uuid[6:8], uuid[8:10], uuid[10:]), nil

func main() {

	        http.HandleFunc("/gettoken", func(w http.ResponseWriter, r *http.Request) {
		uuid, err := newUUID()
		var apiLogin string = "YOUR_LOGIN"
		var transactionKey string = "YOUR_PUBLIC_KEY"
		var liveMode string
		var url string

		if liveMode == "on" {
			url = "https://api.authorize.net/xml/v1/request.api"
		} else {
			url = "https://apitest.authorize.net/xml/v1/request.api"
		fmt.Println("URL:>", url)
		var jsonStr = `{
  "securePaymentContainerRequest": {
        "merchantAuthentication": {
     	"name": "` + apiLogin + `",
		"clientKey": "` + transactionKey + `"
    "refId": "12345",
    "data": {
      "type": "TOKEN",
      "id": "` + uuid + `",
      "token": {
        "cardNumber": "4111111111111111",
        "expirationDate": "122025",
        "cardCode": "900",
        "fullName": "Mary Jones"

		req, err := http.NewRequest("POST", url, strings.NewReader(string(jsonStr)))
		req.Header.Set("X-Custom-Header", "Nexus Web Development")
		req.Header.Set("Content-Type", "application/json")

		client := &http.Client{}
		resp, err := client.Do(req)
		if err != nil {
		defer resp.Body.Close()

		fmt.Println("status:", resp.Status)
		fmt.Println("headers:", resp.Header)
		body, _ := ioutil.ReadAll(resp.Body)
		fmt.Println("response", string(body))
		fmt.Fprintln(w, string(body))
	     // fmt.Println("jsonStr:>", jsonStr)


	// Start the server at http://localhost:9000
	log.Fatal(http.ListenAndServe(":9000", nil))


 It is just as easy, if not easier, to get server side tokens generated using other languages as well.

on ‎10-12-2017 01:21 PM

I agree with 

on ‎06-15-2018 11:37 AM

It would be helpful to have a testnonce. Yes, you can use the authorize.net api to get a nonce but it just makes your test all the more fragile. We're not trying to test authorize.net, but how our system behaves when it is given a valid nonce.

on ‎07-24-2018 11:49 AM

This would be very helpful.  Having test nonce values would be very helpful in developing software to use Authorize.net's accept api quickly and effortlessly.  I've just finished immplementing the square payment api which has a similar iframe square hosted credit card form that returns a nonce value.  However, square supplies several different test nonce values which can only be used when submitted to their sandbox api envirnment to assist with rapid development.  I believe that any company creating api software for developers to consume should do whatever possible to make immplementation both fast and secure.  Providing test nonce values that can only be used when in "sandbox" mode can help speed development for new Authorize.net customers and still be just as secure when in "Live" mode.  I'm dissapointed that Authorize.net does not have this ability yet.