Reply
Member
Posts: 2
Registered: ‎04-04-2019

UUIDs for refIds, invoice numbers, etc.

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.

Highlighted
All Star
Posts: 733
Registered: ‎11-05-2018

Re: UUIDs for refIds, invoice numbers, etc.

@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.
Member
Posts: 2
Registered: ‎04-04-2019

Re: UUIDs for refIds, invoice numbers, etc.

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.

All Star
Posts: 733
Registered: ‎11-05-2018

Re: UUIDs for refIds, invoice numbers, etc.

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.