Send Payments

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?

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

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.

+1

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.

Really keen for this. Any rough ETA?

Are there any updates / ETA for payments API?

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

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.

@johnmee

@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.

@johnmee

@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.

Any updates? It's been a while 😄

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

Can we get an explanation for the reasons behind the comment deletions.
This genuinely looks like someone silencing a whole topic they don't want to have happen rather than engaging and addressing the problem that this now deleted history poses.

@0xdevalias

(Note to Up moderators: feel free to also mark this comment off-topic as needed, personally I feel like that is a fine trade off between "don't clutter the thread with technically unrelated things" and "providing relevant contextual updates at the relevant locations")

@0xdevalias: I have now also raised the way this has been handled as an official complaint through the Up app

@AUSBird: Can we get an explanation for the reasons behind the comment deletions.

Update RE: The formal complaint I raised with Up; while they responded fairly quickly in a 'support triage' way the other day, they have now given their more thorough/investigated response. I will include both for transparency / context.

2026-08-18: Initial support triage

Initial support triage (not sure of exact timing, but basically on the same day that I raised the complaint, probably not too long after):

Hey Glenn 👋

Hope you're having a lovely arvo, and thanks for reaching out about this! I can confirm that this would need to be reviewed further as we wouldn't have the info now to discuss further.

With that said, I have raised this with our internal team alongside our engineers to have a look through what you've raised here alongside what you've requested. I can't guarantee that we can provide you with everything you've requested, but I really appreciate your thoroughness here with getting it all written down 🤝

Once the team has had a chance to review all the information here, they will reach out to you. Most likely you'll get a response during business hours so please keep an eye on your notifications in the meantime.

2026-08-21: Up's 'Investigated Response'

More substantial 'investigated response' (that I received today (2026-08-21) at 2:28pm):

Hi Glenn,

We have received your complaint in regards to our handling of the comment thread on the Up Developer API repository. Thank you for raising the matter with us.

Our public forums, including the Developer API, exist to foster open innovation and collaborative problem solving. It is a unique offering not just as a technical service, but because of the engagement we get from folks like yourself. We deeply appreciate our developer community and everyone who chooses to contribute to our platform, and want you to understand why we took the actions that we did.

Following an internal review of the recent activity, we deleted the thread due to safety risks associated with the public repository. While references to this tool were allowed while it remained private, its public release exposed users to potential security threats without proper oversight. As customer safety is our number one priority, we took immediate action to remove the thread and maintain platform integrity.

In our effort to act swiftly, we acknowledge that several good faith contributions - including constructive feedback and valuable community insights - were also removed. We appreciate these actions were abrupt and apologise to those who had engaged in an open and transparent manner.

To maintain a safe, transparent and collaborative environment, we are taking the following actions:

Restoring context: while individual deleted comments cannot be restored, we have reviewed the archived thread and will add a summary of the information that is relevant back in to the issue.

Establishing community guidelines: this incident highlighted a need for formal community standards. We are creating explicit guidelines, and we will take your complaint feedback into consideration when drafting them.

Updating our terms & conditions: we are revisiting our terms to more clearly define acceptable and prohibited uses of our APIs and application interfaces.

We welcome and celebrate open source contributions using the Developer API and will continue to do so. We hope you can see that the actions we took were necessary to protect the community at large, and thank you for your contribution.

Finally, I appreciate you patience on this matter while we investigated your complaint. I also want to apologise, we were unable to respond in the same thread where you raised your complaint as unfortunately that chat thread was resolved. This meant that we needed to create a seperate message in order to respond and address your concerns. I hope that is ok.

Please do reach out if you have any further questions / concerns on this subject.

Thanks,

2026-08-21: My personal /2c based on that response

Based on that 'investigated response', I suspect that 'soon' we will likely see:

an update on this thread with context of what was removed/why/similar
some creation/updates to the community guidelines on this repo to make the 'rules/boundaries' clear/explicit
updates to the terms and conditions (that I assume will probably make it explicit that 'private' / 'non-documented internal APIs' are explicitly not allowed to be accessed, even if it might be a legally allowed/grey area/similar (as was implied earlier in the thread, unverified by me, since deleted); or at least, that would be my default guess of how a bank would tend to react to a situation like this traditionally; I am open to being pleasantly surprised though.
- This line in particular feels like it leans/implies that way somewhat heavily: "We welcome and celebrate open source contributions using the Developer API"

All in all, I don't think anything there sounds particularly unreasonable / unworkable in general; though, while it hasn't been explicitly stated in that response, if my suspicions about 'updating our terms and conditions' are correct, then that would be a somewhat sad (if not expected) outcome from this; and I would hope that in doing so they would also pair it with a prioritised and feature-complete update/support to the actual supported developer API as a reasonable balance, and not just 'wave a big stick' while providing nothing to fill its place.

If I were to suggest a particularly positive and progressive / repairing stance that Up could choose to take (instead of just 'legal butt covering' / 'locking down'), I would be very impressed if they chose to make a commitment to making the developer API a 'first-class supported product' (bonus points if they were to make it a requirement of newly shipped features being 'ready' to also include support for them in the developer API), and not just something that only seemingly sees love based on the "individual efforts of engineers pushing things through on their own steam" leading to idealised and possibly not quite aligned to the reality of things cases of "it’ll likely be a slow cadence of updates on the developer API in the next year" / similar.

The fact that improvements have apparently happened through individual initiative reflects well on the people who cared enough to make them happen, but it is not a sustainable substitute for product ownership, a published direction, resourcing, and an ongoing relationship with the technically engaged customers who use and extend Up. That would be a much more compelling response to the community demand that has produced unofficial tooling. A well-supported API would give Up a constructive way to meet that demand safely, rather than leaving users and developers to fill the gaps themselves.

(Note: ~~I haven't responded to that main support thread yet; I wanted to capture an update here for everyone first. When I do respond,~~ I will likely just edit this comment to add the new context, rather than creating new ones and driving this particular issue further off-topic)

2026-08-21: My reply to the 'Investigated Response' from Up

The following is the text I sent in reply to Up's 'Investigated Response', via the support chat:

Thanks for taking the time to investigate this properly and provide a substantive response. I appreciate the explanation, the acknowledgement that some good-faith contributions and useful context were caught up in the removals, and the apology for how abruptly that was handled.

The proposed actions all sound constructive to me as well, particularly restoring the relevant historical context, establishing clearer community guidelines, and making the boundaries around supported/unsupported interfaces more explicit.

I also noticed that my later follow-up on the GitHub issue was hidden as off-topic rather than deleted. Personally, I think that is a pretty reasonable moderation trade-off in cases like this: it avoids cluttering a technical issue with meta-discussion while still preserving the context and historical record for anyone who wants to expand/read it.

One thing I would be interested in, if you have even a very rough idea at this stage, is the expected timeframe for the follow-up work you mentioned; particularly the restored context/community guidelines, and separately the Terms & Conditions changes. I appreciate some of that may need wider or legal review, so I’m not looking for a firm commitment; even an approximate "days/weeks/months" sort of indication would just be useful context.

I can also understand the general concern that making tooling around undocumented/internal interfaces readily accessible lowers the barrier to people using functionality without necessarily understanding the risks involved. My main concern was less with Up drawing a boundary around that specific tooling, and more with the broader context and good-faith discussion being removed along with it, so I’m glad that distinction seems to have been recognised in the review.

That also leads into one broader product point I’d really encourage Up to consider as part of the response to all of this: if clearer boundaries are going to be established around unsupported/private interfaces, I think the most positive counterpart would be to make the supported Developer API a more capable and explicitly first-class part of the Up product, rather than primarily closing off the avenues people have used to fill those gaps themselves.

The demand that produced unofficial tooling in the first place is also a useful signal: technically engaged customers want to build richer automations and integrations around their own finances than the current public API allows.

Ideally, I’d love to see that translate into things like:

clear product ownership and ongoing resourcing for the Developer API, rather than improvements depending mainly on individual engineers finding the time and motivation to push them through;

some published direction or roadmap, even if deliberately high-level and non-committal;

broader coverage of the capabilities available in Up itself, including long-requested functionality such as payments where it can be exposed safely; and

at the more ambitious end, treating appropriate Developer API support as part of the readiness criteria for new Up features, rather than something that may or may not arrive separately much later.

I also appreciate that the Developer API may currently serve a relatively small proportion of Up’s overall customer base, and that this affects how it competes for engineering priority. But I think that is partly shaped by the API’s current scope: it is primarily geared toward individuals building things for their own accounts, rather than supporting OAuth or similar delegated access that would enable richer hosted/shared applications and experiences. I also recognise that expanding in that direction would introduce a materially different risk profile (particularly where write capabilities are involved) and would need appropriately strong permissions, consent and safety controls.

Even within those constraints, though, I think this incident creates an opportunity to turn what started as a fairly negative interaction into something genuinely positive: give technically engaged customers a safe, supported and capable path to build the things they are clearly motivated to build anyway.

A strong official API is also, in its own way, part of the safety solution; the better the supported path meets legitimate user needs, the less incentive there is for people to reach for unsupported alternatives, along with the additional and less controllable risks that come with them.

More broadly, policy changes and clearer prohibitions can establish important boundaries, but they are unlikely on their own to remove the underlying motivation of a technically capable user who feels significantly constrained by the supported options. If the demand remains unmet, some people will continue looking for ways around those limitations regardless, potentially creating an ongoing enforcement/cat-and-mouse problem that consumes effort on both sides without addressing the underlying need, which seems like a waste for everyone involved.

Providing a sufficiently capable supported avenue seems like a much better outcome where practical: Up gets to define the security model and appropriate guardrails; developers get useful capabilities without needing to reverse-engineer around them; and Up can turn that technical openness into developer goodwill, advocacy and a genuinely distinctive part of its brand. That feels much closer to a win-win-win than relying primarily on progressively stronger restrictions.

I’d also appreciate it if this broader feedback could be shared with the right people across Up who are in a position to shape the longer-term direction here. I think there’s an opportunity for this to become a genuinely positive outcome across product, engineering, safety and community engagement; not just for the Developer API in isolation.

Thanks again for taking the time to investigate this and for the constructive response. I really appreciate it, and I’m keen to see where the follow-up work lands.

For completeness/transparency, I’ve also shared your response and my broader thoughts with the GitHub community here, and I’ll keep that comment updated with my reply here and any relevant follow-up:

#16 (comment)

(Screenshots below)

Note: The attached screenshots were of an earlier version of this comment before this update I just added; so I won't bother re-including them here.

2026-08-22 (Sat): Up's Response

Morning Glenn,

Thanks for following up.

These are great questions - unfortunately not ones I'm able to commit to answering in full I'm afraid. As a financial institution, there are a huge amount of moving parts where any sort of change is required - particularly in events where we're considering changes to our terms and conditions because, as you reference, these require both broad and legal review rather than being quick changes we're able to make when we identify something needs clarifying or uplifting. Though I can't right now give a timeframe for uplift to our terms and community guidelines, I can confirm that when we do so we will provide an announcement so that those who it's important to are aware.

I have passed along your additional feedback to our engineering teams - and I'd encourage you to continue to engage with them directly via GitHub, because the feedback is genuinely valuable and they are the best placed (and most knowledgable folks) to chat on the topic!

If there's anything else you'd like to add to your complaint, please let me know and I'll ensure it's documented - otherwise, Glenn, have a fantastic weekend.

2026-08-24 (Mon): My Reply

Thanks for the follow-up. That all makes sense, and I appreciate the clarification.

I completely understand that the Terms & Conditions and community-guideline work may involve broader internal/legal review and that you can’t reasonably give even a rough timeframe at this stage. Knowing that there will be an announcement when those changes are ready is useful enough for now, and I’ll keep an eye out for that.

I also appreciate you passing the broader Developer API feedback along to the engineering teams. I’ll continue engaging through GitHub where relevant, and hopefully some of the ideas I raised can feed into the longer-term direction there.

I don’t think I have anything further to add to the complaint at this stage. I’m happy with the way it has been investigated and responded to so far, and I’m interested to see how the promised follow-up work develops from here.

Thanks.

G

2026-08-24 (Mon): Up's Response

Thanks so much Glenn - I appreciate the kind words and look forward to seeing what our engineers are able to bring to the API for you to use!

Take care, and reach out any time, I'll close this complaint off here.

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

@ Up - when you eventually come back, this comment was made - quite explicitly - over six years ago, so hopefully you understand the frustrations.

While I understand and appreciate the security concerns with allowing transfers to happen from one account to another, that risk is significantly reduced if you only allow transferring between your own accounts. Even that would be a good step in the right direction.

Oh, and please build a web/desktop frontend :)

@terrym19

that risk is significantly reduced if you only allow transferring between your own accounts. Even that would be a good step in the right direction.

@terrym19 While it's not quite the same as "is exposed in the developer API"; if you use iOS, there is an Apple Shortcuts feature exposed by the Up app that does actually let you create shortcuts / automations for moving money between your existing accounts. I first stumbled upon it after a suggestion by one of their support agents.

So useful if you're on iOS; and serves as prior art that at least risk-wise they were comfortable enough exposing 'transfer between my own accounts; automated on my own device'; but obviously not the full solution wanted / mentioned in that older comment.

Navigation Menu

Repository navigation

Send Payments #16

32 remaining items

2026-08-18: Initial support triage

2026-08-21: Up's 'Investigated Response'

2026-08-21: My personal /2c based on that response

2026-08-21: My reply to the 'Investigated Response' from Up

2026-08-22 (Sat): Up's Response

2026-08-24 (Mon): My Reply

2026-08-24 (Mon): Up's Response

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Send Payments #16

Description

Activity

d11wtq commented on Jul 29, 2020

balupton commented on Jul 31, 2020

andrewpriceau commented on Jan 13, 2021

frasertweedale commented on Mar 26, 2021

cynix commented on Dec 15, 2021

s8m7p commented on Jul 28, 2022

liamzebedee commented on Sep 13, 2022

johnmee commented on Sep 13, 2022

cynix commented on Sep 13, 2022

liamzebedee commented on Sep 13, 2022

xMdb commented on Jul 5, 2023

arichtman commented on Mar 19, 2024

32 remaining items

0xdevalias commented on Aug 18, 2026

AUSBird commented on Aug 18, 2026

0xdevalias commented on Aug 21, 2026

2026-08-18: Initial support triage

2026-08-21: Up's 'Investigated Response'

2026-08-21: My personal /2c based on that response

2026-08-21: My reply to the 'Investigated Response' from Up

2026-08-22 (Sat): Up's Response

2026-08-24 (Mon): My Reply

2026-08-24 (Mon): Up's Response

terrym19 commented on Aug 23, 2026

0xdevalias commented on Aug 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions