Send Payments

[mkemka]

This is a great api. I know there is another comment about roadmaps but is there a plan to actually create a payment through this API?

[d11wtq]

:wave: Yes, making payments and transfers will be added to the API.

[balupton]

Looking forward to it to knock off this use case

App Idea: Todo list that punishes you financially by donating costs assigned to each task to a charity that you despise.

For instance: A democrat fails to accomplish task X by the deadline, which they associated $5 in value, the app then sends the $5 to the republican party.

[andrewpriceau]

+1

[frasertweedale]

Bring it on! Banking-as-clicking-buttons-in-a-web-UI is soooo 2010. Let me refactor my finances and replace all the tedious manual twiddling with a very small shell script.

[cynix]

Really keen for this. Any rough ETA?

[s8m7p]

Are there any updates / ETA for payments API?

[liamzebedee]

Um. Is this ever eventuating? I was very surprised to learn this isn't part of the API.

[johnmee]

As much as I like the simplicity of stuffing a secret into the header of an https connection, and although I do not really know enough about it to really know, it doesn't strike me as sufficient to keep 'the bad guys' at bay.

We are talking about the programmatic ability to spend money. I expect the security arrangements are exhaustingly tiresome. Not to mention the protocols around what to do after you accidentally and randomly distribute your entire life savings during a "test" run of your script.

Still, someone could throw us a bone, with a hint on how the authentication and authorization will be established, maintained, revoked, etc? And potential mishaps resolved? Any implementation details at all.

[cynix]

@johnmee this wouldn't be much different from, say, the PayPal API to send money, or any other type of "destructive" APIs. The user of the API is obviously responsible for any actions they take. Can't see why it would require additional authentication mechanisms beyond what is already considered secure. At most I'd expect maybe we'll have to sign some kind of agreement that all sent payments are irreversible before this feature is unlocked on our accounts. If you want to test your script, you should be running on a staging/sandbox environment.

[liamzebedee]

@johnmee this wouldn't be much different from, say, the PayPal API to send money, or any other type of "destructive" APIs. The user of the API is obviously responsible for any actions they take. Can't see why it would require additional authentication mechanisms beyond what is already considered secure. At most I'd expect maybe we'll have to sign some kind of agreement that all sent payments are irreversible before this feature is unlocked on our accounts. If you want to test your script, you should be running on a staging/sandbox environment.

I understand the concern here from @johnmee. One thing you can do to reduce the risk is design mechanisms into the API that reduce these risks. Some common examples are circuit breakers / daily limits for the outflow of currency. A payments API could set these limits to be low initially to reduce the chances of devs screwing up.

[xMdb]

Any updates? It's been a while 😄

[arichtman]

Fully transferring money may be problematic, perhaps start with initiating payment requests between Up accounts? I'd really like to be able to auto shuffle my money around based on schedules and quotas

[mathewparet]

I see a lot of security concerns. So probably not a good idea to enable transfers. Or at-least Up should implement some kind of anti-"app-fraud" measure to make sue the app isn't fraud.

However, I'd think that transfer between spending to savers and vise versa within the same up account must not face a security concern as such. In fact, I have a scenario I would like to automate - I have a Tesla and would like to move the cost of charging into an "Electricity". I'd like to automate the process such that as soon as charging is done at home, the cost of charging is calculated and the amount is moved from Spending to the "Electricity" saver.

[balupton]

Just do what other API / automated banking apps do, where one can trust the connected app completely (no auth, or within limits — amount limits or permit to only certain accounts), or keep it semi-trusted where connected app transactions are queued until manual user approval, either via the Up App or a 2FA method.

[0xdevalias]

or keep it semi-trusted where connected app transactions are queued until manual user approval, either via the Up App

This would be a nice mix of 'ease of use' with explicit 'human-in-the-loop' safety. It would be SO much less effort to just have to tap a button per transaction (or select the ones I want) to confirm in-app; rather than having to manually write out the full transaction details from my phone each and every time.