Gravy uses base62 (not 64) encoding to convert its UUID-style transaction IDs to a shorter reconciliation ID. They send the reconciliation ID as the merchant ID to the backend processors.
To make it easier for donor services and payments folks to have one ID linking the payment in all three places—CiviCRM, Gravy console, and the backend processor console—we're going to use the existing Gravy transaction ID to generate and display the reconciliation ID on the fly in CiviCRM under the existing contribution_extra data.
We should probably add some indication that the field is dynamically generated to save our future selves from scratching our heads as to why we can't find it in the database.
Gravy said they are going to send over more info on the encoding. @Ejegg also found this https://medium.com/@huntie/representing-a-uuid-as-a-base-62-hash-id-for-short-pretty-urls-c30e66bf35f9