UUIDs for refIds, invoice numbers, etc.

[zachmay]

My system uses UUIDs for all of its IDs (customer IDs, invoice IDs). It would be nice if I could use those UUIDs directly when making createTransactionRequest calls, but many of these have 20 character limits.

Is anyone else using UUIDs in this way and can suggest a safe way to compress these UUIDs for use with the Authorize.net API?

Devs: Is there any chance those limits could be increased? UUIDs are pretty common, so this limit seems odd.

[Renaissance]

@zachmay

Few questions- 1: how many fields do you need to pass for your UUIDs? You have 2 per order? And you need how many characters? 2: what is your purpose for passing the UUID in the transaction? Is this so that you can retrieve it from authorize later, or simply so that your customers will see it on their payment page and/or receipt? 3: what integration are you using? Do you use a hosted payment form?

Depending on these, you have a few workarounds. The invoice number can be passed under the PO number, which has 25 characters. If you use a hosted form and need to link internal orders to auth.net transactions that may be a good solution.

If you are passing for retrieval from authorize at a later time, my go to workaround is to use any and every field available. I just pick one that I’m not already using and pass what I need to pass there. The only consideration is some of these items will display on the hosted payment page and/or receipt. You don’t want to do something that will overly confuse your customers.

Also, for any and all purposes, you can truncate the invoice number and customer ID and pass it to authorize without losing the Ids uniqueness. If you have a 25 or 30 or 40 character invoice number, there would have to be a section of that ID that is 20 characters or less that is unique to that invoice.

[zachmay]

We're using Accept.js with our own payment form.

Simply truncating UUIDs seems like a really bad approach. That would greatly increase the chance of collisions. Shoving data in strange places also seems like a pretty undesirable solution.

Ideally, I want to use the ref ID and customer ID fields as they're intended (less weird behavior to document, in the future we may want to use ref ID *and* purchase order ID, etc.), but that doesn't look like it's going to be possible. It's pretty silly.

[Renaissance]

Yeah lol. “Shoving” is an interesting way to describe it. That’s what I do though and it works like a charm. I use the whole caboodle and we can retrieve nearly anything we need. Great way to back up data. Regarding collisions I understand that concern but if I were you I’d be liking my odds. 20 characters is a lot, a lot lot. If you only have numeric values your chance would hit 1% at about 100 million users.

[mindtonic]

Jumping in on this one too. We don't use any numeric priary keys for many reasons. This is becoming a fairly modern trend in development. It would be tremendously helpful if we could map our invoice and user IDs directly to Authorize.net so that consistency is maintained across our system. Would it be possible to have the string charachter limit increased to accomodate UUIDs?

[mindtonic]

+1  We don't use any numeric priary keys for many reasons. This is becoming a fairly modern trend in development. It would be tremendously helpful if we could map our invoice and user IDs directly to Authorize.net so that consistency is maintained across our system. Would it be possible to have the string charachter limit increased to accomodate UUIDs?

[mindtonic]

Sorry for the double posting. Creating an account had a few more hoops than I expected.

[f4f57c39-834d-4]

Caller-supplied IDs, including refer ID and customer ID are limited to 20 alphanumeric characters according to the specification.  As these are caller-supplied IDs, this imposes limitations on the calling system.  This limitation can obviously be met with additional coding, storage, and locking, but why should the payment gateway interface impose this design on the calling system's IDs?

The field restriction requires uniqueness, which requires global locking of some form, and is essentially what UUIDs are intended to avoid by providing non-locking globally unique IDs (or at least IDs with a very high probability of not colliding).

If it is possible to change it, extending it from 20 characters to 22 characters would be enough (base 62 encoding of a 128-bit UUID can be done in 22 characters (62 = 2x26 + 10; case-sensitive strictly alphanumeric characters).  More convenient would be extending it to 36 characters, including dashes, or 32 characters without dashes - these could support UUIDs without base conversion.