Payment experiences
Approved integrations may create hosted checkout sessions, payment links or supported bank-payment journeys.
Developer gateway
Payment API for Australian platforms and software
The ShaBaas Pay payment API helps eligible Australian platforms and software products initiate or present supported payment experiences and receive payment status through APIs and webhooks. Detailed endpoint behaviour, onboarding, permissions and production availability depend on the approved integration, current documentation and the specific fund flow.
Capability overview
What can the payment API support?
Agreement and status workflows
Where enabled, an integration can work with PayTo agreement requests, payment status and lifecycle information.
Reporting and webhooks
Use asynchronous status events and reporting retrieval to connect payment operations to the platform workflow.
Exact endpoints, fields, authentication schemes and supported capabilities belong in the canonical technical documentation. Do not infer production support from a marketing description.
Build with operational readiness
What is the typical integration workflow?
Review the use case
Confirm the business model, customer journey, fund flow, payment methods and onboarding requirements.
Start in a test environment
Obtain the appropriate credentials and exercise success, failure, timeout and customer-action paths.
Connect server to server
Implement validation, authentication, idempotency, retries, webhook verification and duplicate prevention.
Prepare production
Complete approval, monitoring, reconciliation and support checks before enabling the live flow.
Architecture at a glance
How the payment API fits a platform
| Layer | Responsibility | Operational question |
|---|---|---|
| Platform backend | Creates the approved request and stores its business reference | Can the request be safely retried? |
| ShaBaas Pay API | Processes the configured payment or hosted experience | What permissions and method are available? |
| Customer experience | Customer completes checkout or bank authorisation | What action is still pending? |
| Webhook and status | Returns asynchronous changes to the platform | Are events signed, duplicated or out of order? |
| Ledger and reconciliation | Matches payment outcome to the platform record | What is the source of truth for exceptions? |
Integration decisions
Design for payment operations, not only the happy path
Request safety
Use request validation, idempotency and duplicate prevention so retries do not create unintended payment actions.
Asynchronous status
Model pending, completed, failed or rejected outcomes and do not treat an API response as proof of final payment success unless the docs say so.
Webhook reliability
Verify webhook authenticity where supported, handle retries and out-of-order events, and monitor delivery failures.
Reconciliation
Keep a durable business reference, transaction status and exception queue connected to the platform ledger.
Build or use a hosted implementation?
A full API integration gives the product team more control over the payment experience and state model. Hosted checkout or payment links can shorten time to market and reduce UI responsibility. Choose based on engineering capacity, user-experience needs, payment-state complexity and reporting requirements.
Supported business contexts
Where an API-led workflow may fit
- SaaS billing and approved recurring payment workflows
- Professional-service and invoice platforms
- Booking, membership and education systems
- Software products that need payment status in their own workflow
- Platforms that need hosted payment experiences with server-side reporting
- Use cases where onboarding and fund flow have been reviewed
Marketplace split payments, sub-merchant settlement and multi-party payouts are not implied by this page; review those fund flows before making a product commitment.
Frequently asked questions
Questions developers ask
What payment methods can the API support?
Depending on the approved integration, the API may support PayTo, PayID, Pay by Bank, hosted checkout, payment links and other configured payment methods. Confirm the current documentation and permissions for the intended flow.
Is there a sandbox?
Ask ShaBaas Pay or consult the current developer documentation for sandbox availability, credentials and supported test scenarios.
Are webhooks available?
Supported integrations can use webhook or status-notification patterns where available. The implementation must follow the current documentation for verification, retries and event handling.
How should an integration handle duplicate requests?
Design idempotency and duplicate prevention into the server-side workflow, using the current API documentation rather than inventing request fields or behaviours.
Does the API replace accounting software?
No. The API supports payment collection and status workflows. The client or platform can retain its accounting or ledger system as the system of record.
Can a platform use hosted checkout instead of building a full payment UI?
Where the configured product supports it, hosted checkout can provide the customer-facing payment experience while the platform integrates the surrounding workflow and status handling.
What is required before production access?
Production access depends on onboarding, permissions, use-case review, technical testing, security controls and approval for the intended integration.
Developer resources
Continue the implementation review
Plan the integration around the fund flow
Share the platform workflow, payment methods, customer journey and reporting needs for a technical fit discussion.