The use case we are addressing is where a customer needs to pay an invoice they have received from a supplier who uses QuickBooks and Intuit Payments, and wants to send that payment via card. We want to build an app that connects to the supplier's QuickBooks account to process the payment via Intuit Payments, and record the transaction as a Received Payment in QuickBooks (applied against the invoice being paid).
Fore more detail, see sequence diagram attached, text summary below:
1. The supplier invokes our app by clicking a “Connect to QuickBooks” button that would be embedded in a (simulated) enrollment email from the customer
2. Clicking the button invokes a connection of our app to QBO (via Intuit Anywhere QBO API)
3. Also passes to our app via a url parameter a recipient id (used as an account identifier for the supplier in our app - could be email, but perhaps better not)
4. App displays UI to get the user's permission to process the payment via card, via a checkbox displaying: “Ok to accept card payments for open invoices from this customer?”
5. After completion of these enrollment steps, triggers processing of any pending payment(s) as follows.
6. Retrieves details of pending payments for that supplier from some data store (TBD) including both card payment and remittance details (for, now just the simplest case: a single invoice number).
7. Calls QBO APIs to…
a) Find the QBO Invoice matching the invoice number from the payment remittance
8. If found, calls an (Intuit Payments) API to process that payment
9. If payment was successful, calls QBO API as needed to…
a) Retrieve QBO internal references for the Customer to whom the matched Invoice was issued
b) Save to QBO a Received Payment, applied against that Customer and Invoice
The above items are the first milestone. The second milestone to complete this initial proof-of-concept is:
10. The addition to the data store of any new payment record for an active supplier should trigger an event that drives the real-time retrieval and processing of that payment, via the same steps described above (i.e. via some event mechanism, such as SignalR / Websockets / Webhooks, and NOT via continual polling).
Although demos of the PoC will likely correspond to a single user account, the system should support multiple such accounts. The demo flow would typically work like this.
1. Pre-populate one payment transaction in the data store, associated with the QBO user's email (or, better perhaps, some other id)
2. Generate a "Connect to QB" button pointing to our app, but which also includes said id as a parameter
3. The user clicks that button to initiate activation of an account for that id in our app, and the connection to QBO
4. After completion of the auth / connection setup steps, the app checks for any waiting payment transactions for that id - and if there are, it processes them as described above.
Building the PoC in the fastest and most expedient way is what's most important. I am interested to hear what tools and platforms you would recommend.
There are, however, cloud integration platforms that may make this initial development easier - and also potentially more reusable for later. I am particularly interested to hear about your preferences and experience with Microsoft platforms, and in particular Microsoft Azure.