
Starling Bank payments API Integration for Payroll App
- or -
Post a project like this- Posted:
- Proposals: 29
- Remote
- #4470994
- OPPORTUNITY
- Awarded




Description
Website: https://paycis.co.uk
The payroll logic, approvals, logging, and manual payment fallback are already built.
We now want to add automated payments for users with a Starling Business bank account.
⸻
What we need
A developer to integrate Starling Bank’s native Business API so approved payroll payments can be executed directly from the user’s own Starling account, with automatic success/failure updates.
This is:
• ✔ Bank-native API
• ❌ Not Open Banking
• ❌ Not file uploads
• ❌ No client money handling
⸻
Scope
1. Starling account connection
• Implement Starling OAuth (connect / disconnect)
• Secure token storage and refresh
• Reuse existing OAuth patterns where possible
2. Payroll payment execution
• Use Starling Business Payments API
• One API call per payment (10–50 per run)
• Store paymentUid and prevent duplicates
3. Payment status updates
• Handle Starling webhooks
• Mark payments as paid or failed
• Log outcomes and failure reasons
4. Error handling
• Insufficient funds, invalid details, revoked tokens
• Retry or fall back to manual payment
⸻
Deliverables
• Starling OAuth integration
• Payment execution logic
• Webhook handling
• Brief technical notes
⸻
To apply
Please include:
• Relevant bank / payments API experience
• Confirmation this is Starling Business API (not Open Banking)
• Estimated timeline and FIXED cost. Note that we do not accept estimated or open ended costs, only a FIXED price. Please confirm this in your response.
Robert B.
100% (11)New Proposal
Login to your account and send a proposal now to get this project.
Log inClarification Board Ask a Question
-

Hi Robert, quick clarifiers before I price this as a fixed amount:
1. What’s your stack/hosting (framework + DB), and is there an existing OAuth pattern in-code we should reuse?
2. Do you already have Starling Business sandbox + webhook setup (public webhook URL + signature verification approach)?
3. What are the “done” acceptance checks you want us to evidence (e.g., success + insufficient funds + revoked token + invalid details) and should we include idempotency/locking to prevent duplicates on retries?Robert B.06 Feb 2026Hello, thank you for your message. In response to your questions:
1. Stack / OAuth
We already use OAuth for HMRC VAT APIs, so token storage and refresh patterns exist. Starling will reuse/extend this on a per-organisation basis. Stack details can follow.
2. Sandbox / webhooks
Starling app registration is in progress. Sandbox access will be available and we’ll expose a public webhook endpoint. Please include signature verification.
3. Acceptance / idempotency
“Done” = handling of success, insufficient funds, invalid details, and revoked/expired tokens. Yes, please include idempotency/locking to prevent duplicates.Eight Veer Ltd06 Feb 2026Hi Robert, thanks, that’s really helpful. Based on what you’ve confirmed (reusing your existing HMRC OAuth pattern, Starling Business API with webhook signature verification, and idempotency/locking with the 4 acceptance scenarios), I’ll put together a fixed-price proposal with a clearly bounded scope, acceptance checks, and handover notes. I’ll send the proposal shortly.