Test Opaque Token

[mlunn01]

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.

[BrandonSurowiec]

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.

[Mirimon]

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.

[Aaron]

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.

[Auctra]

+1

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.

[NexusSoftware]

Spoiler

 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 (
	"crypto/rand"
	"fmt"
	"io"
	"io/ioutil"
	"log"
	"net/http"
	"strings"
)

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) {
		r.ParseForm()
		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 {
			panic(err)
		}
		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.

[swalker2]

I agree with NexusSoftware, I could easily generate a token for unit testing by replicating the data sent by Acceptjs to authorize.net

[glyoder]

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.

[cvadmin1]

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.

[Mosquiche]

---

@mlunn01 wrote:

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. RapidFS

---

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.