api support for external_order_id field against which to generate invoice

georgeartem

In an e-commerce environment, an external ecosystem will generate some orders as their customers go to check-out, when an order is generated and is assigned both a store_hash and a order_id any service using GigaWallet will need to track pending/completed transactions against both.

For the store_hash this is simple - we can use the account api to create a record for the merchant, but for the order it is a little more complicated. We would need to track invoices against specific orders by their order_id in order to track what is being paid and requires fulfillment.

Does an 'external_order_id' field exist that could be passed in the POST request to some.domain:8081/account/[store_hash]/invoice so that it can be included in the response to the external app once the invoice is generated?

tjstebbing

The idea was that systems would store the invoice ID on their order record. Does that work for your situation?

georgeartem

maybe, we would have to talk it through. here is what we have as far as a flow presently:

we implement a "manual" payment method and customer produces an order via check-out, which creates an order_id that has an associated store_id
we send a request to gigawallet to generate an invoice via POST as above
we wait for a response and expect to be able to match the invoice_id with the order that needs to be fulfilled

the dev team seems to believe that our app db_schema could have both order_id and invoice_id in the same row, but I am not fully understanding how we would do the matching of the response as-is without an additional field.

I looked through the gigawallet repo today, and wrote up some minor changes adding this suggested "ForeignID" for the places it would be impacted, but didn't feel comfortable submitting a pull request because I haven't tested it, as the only version I've been able to get to run is what's provided in the dockerfile and all Linux/Windows attempts at running gigawallet locally have resulted in the issue we closed last month.