Can I create an order client side and submit a debit + order together w/o having to create an order from the server first?

[patrickcusack]

https://botbot.me/freenode/balanced/2014-09-09/?msg=21323501&page=1

[mjallday]

If it's created client side that would mean that potentially anyone could create an Order/Debit on your system since currently we require an API key to create resources via the API (apart from cards).

It's not immediately apparent to me how you can allow the client to control creation of resources on the API securely.

Cards are created independently of any marketplace and you perform authenticated requests to claim them so they are controlled in that manner.

What's the use case that prompted this request?

[mahmoudimus]

@mjallday I believe @patrickcusack meant from a client library first.

[mjallday]

Do you mean creating a debit and an order in a single API call?

[mahmoudimus]

Yep, which avoids a roundtrip of 1st creating the order. This is more
important on mobile applications.

On Tue, Sep 9, 2014 at 12:18 PM, Marshall Jones [email protected]
wrote:

Do you mean creating a debit and an order in a single API call?

—
Reply to this email directly or view it on GitHub
#691 (comment)
.

[mjallday]

The Order can be created ahead of time rather than when the user clicks on the "pay" button.

If the user has already tokenized the card then all the marketplace needs to do is create the hold while the user waits. Everything else can occur asynchronously.

We could write a best-practice guide for mobile integrations which could help people understand the best approach methods for writing a responsive app for these situations.

I've seen many concerns about latency while doing several calls inline to an API, not doing them inline is an easy solution but may not be obvious unless you have domain expertise.

[patrickcusack]

At this point I am looking at making 4 api calls to submit a debit were I to do it inline. So you recommend that I have pre-cached order ready, which i use in my reference to my debit. Then do an asynchronous customer and marketplace credit?

[patrickcusack]

"We could write a best-practice guide for mobile integrations which could help people understand the best approach methods for writing a responsive app for these situations."
This would be a good addition to the documentation.

[mjallday]

you recommend that I have pre-cached order ready, which i use in my reference to my debit. Then do an asynchronous customer and marketplace credit?

I think that's the best approach. If I were about to integrate a mobile payment solution I'd try and make sure that the amount of time the user is waiting for a response is minimised.

Since the only call that can fail once the user has tokenized a card is the creation of a hold then that's the only call I'd make the user wait for. Once the hold has succeeded you are guaranteed that you can capture it and create a debit from it (and an Order).

I'd do the flow like:

• tokenize card (sync while user waits)
• prompt for confirmation of order
• user clicks submit/authorize button
• card.hold(amount) (sync while user waits)
• if the previous call failed then prompt user for another card
• if the call succeeded then show them a success screen and in the background capture the hold to create a debit and the order.

You could create the Order ahead of time but since there's no way to currently delete an Order you could end up with unused Orders hanging about if the user abandons the purchase half way through.

This would be a good addition to the documentation.

We have created an issue to follow up on this - balanced/balanced-docs#447

@patrickcusack let us know if you have more questions or comments about how we can improve on this answer.

[patrickcusack]

Why even do the hold if the you could debit the card and get the same instant feedback as you would the hold?

[mjallday]

that's a fair comment, you then have to have created the Order ahead of time. if you're OK with potentially creating Orders and having them abandoned it's no issue.