GraphQL Playground

All the GraphQL queries can be sent via the GraphQL Playground or as a HTTP POST request to https://api.uat.flash-payments.com.au. Example:

echo '{
  "query":
    "{
       quote(input: {
         fromCurrency: AUD, toCurrency: USD, size: 9.9, currency: AUD
       })
       {
         bid ask symbol timestamp inverted
       }
     }"
}' | curl -X POST 'https://api.uat.flash-payments.com.au' \
-H 'authorization: Bearer YOUR_TOKEN' \
-H 'content-type: application/json' \
-d @-

All the responses are JSON and have at least one property data and optional property errors.

{
  "data": { ... },
  "errors": [ ... ]
}

Some of the GraphQL query parameters are required, others are optional. To understand if a variable/property is required you would need to check the API schema.

• Go to the and click the button "DOCS" on the right.

• Browse through queries, mutations, input and output types. Find a variable/property which have an exclamation mark at the end. E.g. fromCurrency: FromCurrency!.

• The exclamation mark denotes that the variable/property is mandatory.

It is a good idea to always send custom user-agent HTTP header value when doing requests to Flash Payments API. Here is why:

• In case of troubleshooting we will be able to trace and mitigate your support questions faster.

• You might be blocked by our automated firewall if your user agent is something generic like curl, Java-http-client, python-requests, Ruby, etc.

Our API have smart monitoring and it may temporarily block your IP if it detects system misuse. For more information, please refer to the page.

A sub-client lifecycle follows these stages.

A sub-client is created and has the temporary INITIATED status. At this stage, the request has been received and the system is currently processing it.

If processing is completed successfully, the sub-client automatically transitions to the ACTIVE. In this status, the sub-client is fully activated and approved.

If the sub-client requires manual compliance review, the sub-client moves from INITIATED to the temporary UNAPPROVED

You can via the createWithdrawal mutation.

You can your payouts via the withdrawals query.

Sometimes you'd need to understand the supported delivery methods using the query.

If you get instructed by another financial institution then you must submit their details too.

If the payouts didn't pass compliance we would reject it with a proper rejection code and descriptive message.

Upon detecting a deposit in a Flash Payments Virtual Account Number (VAN), we immediately record it as a deposit in our system.

The status of a successful deposit goes through the following lifecycle

INITIALISED->REVIEWING→CONFIRMED

If you choose to reject a deposit, its status goes through the following lifecycle instead:

If you use our multi-currency feature, you can exchange currency and between your master accounts in real-time.

Conversion fees are detailed in your contract and vary based on your use case and risk assessment.

The GraphQL schema defines statuses like this:

The status of a conversion can be any of the following:

• INITIALISED — A conversion record was created, but no further action has been taken. This status typically does not occur via the API.

• PENDING — The conversion is in progress. This is the usual status immediately after creation.

For your initial tests, it may be easier and more practical to send data by embedding values directly into the GraphQL queries and mutations, as shown in the example below.

At the same time, to enable efficient and accurate handling of complex queries in code, we support sending GraphQL queries as JSON objects that consist of two properties: "query" and "variables". Here is how you can do it:

• Declare the $input variable in the QraphQL "query"

Most documentation examples utilise typical GraphQL input data for successfully executing queries.

It's strongly encouraged that you always submit complete and accurate data, as this reduces our compliance team's reviewing efforts and, as a result, speeds up transactions and provides a great experience for your customers.

At the same time, we recognise that gathering complete customer information can be technically challenging, particularly regarding country-specific address details or account information. As a result, our API documentation emphasises the required input fields based on the principle of minimal necessity.

Please pay attention to the exclamation mark ( ! ) next to the field type in the API schema specification from the "Docs" section of our API Playground. Those are the required fields as it's demonstated on the screenshot below:

Before doing any other API calls you have to obtain an auth token. It's a standard JWT token carrying the following payload:

The token lifetime is 4 hours at this time. We might change this value in the future.

To be more future-proof, it is recommended to parse the token payload and compare current time to the token's expiration time. JavaScript code:

1. After we enable you, go to the , click "DOCS" on the right to explore the possibilities.

Flash Payments API is -based, offering simple and developer-friendly querying experience. All data is exchanged in JSON format.

Flash Payments API playground is located here:

This documentation website does not have full list of API fields and methods. This is intentional. The full list of the API calls you can performs and the data fields you can send/receive is listed in the (click "DOCS" on the right hand side).

You can search, visualise, or extract your data using our interface.

Once registration is complete, a dedicated BSB and Virtual Account Number (VAN) for use within Australia will be assigned to you.

Any funds deposited to your VAN would increase your Flash Payments balance. We store and retain the reference attached to each deposit (e.g., an invoice number) to support your reconciliation or reporting needs.

Adverse Media Search (AMS) lets you screen an individual or organisation against web-based adverse media sources — news articles, court records, and other publicly available content.

You can via the adverseMediaSearch mutation or past searches via the amsRequest and amsRequests queries. Scans run in the background and can take several minutes. Use webhooks or poll the amsRequest query to track progress. See for the full lifecycle.

1. - query bank information to validate if we support your BSB, IBAN, BIC (aka Swift code).

2. depositDetails - query the accounts you can send deposits to in order to increase your Flash Payments master balance.

If your withdrawal is canceled (aka rejected) by our AML and Compliance team, you'll receive the withdrawal_cancelled webhook containing both a rejection code (rejectCode) and a manually written rejection reason (statusMessage). You can find the same two properties within the withdrawal GraphQL type.

Here is a current list of all possible rejectCodes, but please note this list can be extended with time.

CANCELLATION_REQUESTED_BY_PARTICIPANT
CANCELLATION_BY_RECIPIENT_FI
COMPLIANCE_DECLINED
COMPLIANCE_DECLINED_EXTERNAL
SENDER_INADEQUATE_DATA
SENDER_INVALID_ADDRESS
SENDER_INCOMPLETE_ADDRESS
RECIPIENT_INADEQUATE_DATA
RECIPIENT_INVALID_ADDRESS
RECIPIENT_INCOMPLETE_ADDRESS
DATA_ENQUIRY_TIME_ELAPSED
DATA_ENQUIRY_RESPONSE_INADEQUATE
SOURCE_OF_FUNDS_INADEQUATE
DUPLICATE_TRANSACTION
TECHNICAL_ISSUE
RECIPIENT_ACCOUNT_CLOSED
RECIPIENT_INVALID_ACCOUNT_NUMBER
RECIPIENT_INVALID_BANK_CODE
RECIPIENT_INVALID_ACCOUNT
RECIPIENT_COUNTRY_NOT_SUPPORTED
RECIPIENT_CURRENCY_NOT_SUPPORTED
EXPIRED

Please also note that while the rejection codes are set, the corresponding free text statusMessage will have a case-by-case human written text explaining the root cause of the cancellation. We'll try to be as descriprive as possible taking into account the legal bounds (we are not allowed by the law to disclose certain information).

1. You create a withdrawal. Your balance goes down by the withdrawal amount plus fee. INITIALISED

   1. We might internally review the transaction. INITIALISED-> REVIEWING

   2. If review goes well it will become pending. REVIEWING→ PENDING

   3. Otherwise it gets cancelled. REVIEWING→ CANCELLED

2. The transaction is sent to the recipient bank for processing. INITIALISED → PENDING

3. PENDING →

   • CONFIRMED - the recipient bank has the money now. Does not mean the beneficiary account number was credited though. Mostly FINAL status. Except when bank decides to return the funds, the withdrawal gets refunded (see step 4).

4. The recipient bank decided to return this transaction back to Flash Payments.CONFIRMED → FAILED → REFUNDED - usual way - automatic refunding. Your balance goes up by the withdrawal amount, Flash Payments keeps the fee. FINAL status.

The payout passed our automated compliance checks and was processed successfully:

INITIALISED→PENDING→CONFIRMED

The payout was successfully processed after a manual compliance review:

INITIALISED→REVIEWING→PENDING→CONFIRMED

Recipient bank accepts the payout but then returns it:

INITIALISED→PENDING→CONFIRMED→FAILED→REFUNDED

Recipient bank rejects the payout:

INITIALISED→PENDING→FAILED→REFUNDED

Flash Payments Compliance team rejects the payout:

INITIALISED→REVIEWING→CANCELLED

After fully registering with us, you get a BSB and a dedicated Virtual Account Number (VAN).

Every deposit to your VAN would increase your Flash Payments balance.

Every deposit can trigger a Webhooks notification, keeping you informed in real time

The deposit data includes the payment reference (we call it externalReference in this API).

By default, only you are permitted to make deposits. However, we can enable third-party deposits for your account upon request. Once enabled, your account number functions as a local collection account, allowing others to deposit funds on your behalf.

We can also enable the feature. It allows you to programmatically create client accounts with dedicated BSB and account number for transactional purposes. You can give these bank account details to your clients to accept deposits. Once funds arrive, we will increase your account balance, and you will see a deposit with sub-client information linked to it.

To browse your deposits, you can use our interface.

Refund deposit by ID

const bodyJSON = {
  variables

mutation($id: ID!, $input

{ 
  "id": "6053d4e0e3bc655e0598a742",
  "input": { 
    "amount": 10, 
    "reason": "sent by mistake"
  }
}

{
  "data": {
    "refundDeposit": {
      "success": true,
      "code": "REFUND_SENT",
      "message": "Refund initiated successfully"
    }
  }
}

When sending a payment, creating a local withdrawal or ordering a conversion you can provide us a webhook (callback) URI - callbackUri. We will call it when a payment or withdrawal status changes.

We recommend API clients to generate and add ?signature=ASecretPerPaymentKey query to your callbackUri to make sure it's Flash Payments calling your webhook endpoint. For example:

https://my-webhooks.example.com/flash-payments?signature=oZaDlmfXbdXSKCnuWrvos2ImVBFX2Ru5

To avoid storing the signatures in a database we recommend generating them on the fly using a strong hash function or any kind of cryptography.

Example

You would need to implement two functions.

1. Function to generate "signature".

2. Function to verify the "signature".

Node.js pseudo code to generate a signature in your integration code.

The code above creates a callbackUri and externalId variables. Use both of them when creating a transfer in Flash Payments API.

Node.js pseudo code of your webhook HTTP request handler.

Paste this query to the GraphQL Playground

const bodyJSON = {
  operationName

query balances($currencies: [CurrencyIso3]){

{
  "currencies": ["AUD"]
}

{
  "data": {
    "balances": [
      {
        "currency": "AUD",
        "cleared": 3860,
        "pending": 0
      }
    ]
  }
}

The cleared is the Primary balance you see on the Flash Connect website.

The pending balance is typically not shown on the Flash Connect interface because it's rather short lived. If your Pending balance is not 0 then you can see it right next to the Primary balance.

If you omit the currencies input argument then the query would return all the currency balances you have. Contact us to enable more than just the default AUD currency.

If you need to increase your UAT account balance please sign in to the Flash Connect website, open Deposits page, and click Send Test Deposit.

The sub-client (aka merchant) feature allows you to create client accounts for deposit collection purposes. These virtual accounts can be issued to individuals, companies, or other organisations.

Each sub-client will receive a dedicated BSB and Vitrual Account Number (VAN) that you or your clients can use to accept and withdraw domestic AUD transfers within Australia.

The account name is your sub-client's name. For companies - it's their tradingAsName or legalName. For individuals - it's their fullName (firstName + middleName + lastName).

If your Flash account has a multi-currency feature enabled, each of your sub-clients will also have access to virtual accounts in the selected currencies for which you hold balances.

All sent to your sub-client Virtual Account Numbers (VANs) are booked on your (master-client's) corresponding account balances. Sub-clients can't have their own balances.

You can and on behalf of your sub-clients by providing the sub-client ID when you create withdrawals or payments. This sub-client record will then be used as the sender, linked to the transaction, and reported to the government.

Notifications via will provide important sub-client information as well.

Here is the list of all possible CoP response codes.

Address Cleanser is a data-standardisation and geocoding utility designed to ensure physical addresses exist and are correctly formatted. It standardises a supplied address against multiple geocoding providers and returns a suggested recommendation together with a score.

It helps you:

• Validate and standardise addresses before processing payments

• Reduce failed deliveries due to incorrect or unrecognised addresses

• Support data integrity and screening accuracy by standardising physical addresses

You can cleanse an address via the mutation or retrieve past requests via the and queries.

Unlike Adverse Media Search, address cleansing is synchronous — the result is returned in the mutation response. There is no background processing and no webhooks.

Recommendation and score

The result is an estimate, not a definitive check. Each cleansed address comes with:

Pricing

Address Cleanser is charged per request — 1,000 requests per month are included free of charge. To learn more about pricing, API access, or to enable Address Cleanser for your organisation, reach out to our team.

What we call "FX Payment" is a fully orchestrated account to account delivery of any currency(-ies) we support. Typical examples:

• You need to send from the EU to Australia. You would have a European virtual IBAN on your name. As soon as you deposit some EUR to it - you'll see a corresponding amount of AUD on your master balance in a matter of minutes, which you'll be able to use immediately.

• You need to fund someone's overseas IBAN in Euros. You send us the AUD and give us the recipient's details either via API or via you FlashConnect back-office GUI. We orchestrate the rest.

You can . using the createPayment mutation.

You can your payments with the payments query.

But before you need to understand the supported delivery methods using the query.

To trigger a happy or unhappy path scenario, put the corresponding keyword in the externalReference field when you submit a withdrawal. The keyword instructs our system to automatically simulate that outcome instead of routing the withdrawal through the standard compliance and payout pipelines, which may require manual intervention by a compliance analyst. Typically, you want to adapt your system to handle the following common withdrawal scenarios:

If your withdrawal is in this status this means that we are doing an internal review of it. It happens occasionally when you trigger our monitoring rules. Also, this means that we have sent your Compliance Team (or else) an email message requesting more information. You must respond. In other words, if there is a delay - it's on you. Because Flash Payments delivers all your transactions in real-time 24/7.

You can simulate the behaviour. Your externalReference must include this text: HALT_AML. For example: "testing HALT_AML attempt 2"

This query returns the same data as the Download CSV button on the Account Statement page of the .

The dates must be any ISO 8601 formatted dates.

The response dates are aways UTC. Timezones are always taken into account.

Confirmation of Payee (CoP) is a security feature that verifies whether an account holder's name matches the account details you provide. It helps to:

• Reduce fraud by verifying the account holder's name before sending funds

• Prevent accidental payments to wrong accounts due to mistyped details

The GraphQL schema defines statuses like this:

The status of a payment can be any of the following:

Payment Statuses:

• INITIALISING – a draft payment. It may or may not have all required information to be executed. Typically, this never happens through the API. Can be created via the under certain circumstances.

To convert between, say, AUD and EUR you should:

1. Request a tradeable quote with applicability: CONVERSION.

2. Retrieve the quote ID from the response.

3. Reference the quote ID when creating the conversion.

Get a tradable quote ID:

Convert funds:

Use the declineRfi mutation when you are unable to provide the requested information — the API equivalent of "Unable to comply" on the secure form.

Declining:

• marks the RFI as CLOSED — an rfi_closed webhook is dispatched;

• cancels any linked deposits, withdrawals, or payments still under review at the time of decline, with CANCELLATION_REQUESTED_BY_PARTICIPANT ;

• leaves anything already confirmed, cancelled, or refunded as-is.

If the RFI is no longer PENDING, the mutation returns success: false with code INVALID_STATUS and the unchanged RFI — see .

Limits

This API apply various rate limits depending on the type of HTTP request or GraphQL query being executed, as well as the number of such requests. The rate-limiting mechanism is quite dynamic and is based on the IP address(es), error rates, HTTP headers, and the GraphQL queries.

We do not disclose the exact limits due to their complexity and our security policy. However, it's nearly impossible to reach the limits if your requests are properly formed.

When one of the numerous limits exceeds the API typically responds with

1. the HTTP status 429

2. the HTTP header:

3. and a JSON body:

Here are the common situations when you might get yourself temporarily blocked:

• When your requests produce numerous errors, e.g. malformed header, JSON body, or a GraphQL query.

• When you send too many requests without a valid Authorization header.

• When you send too many requests within a very short period.

Please contact our support team via the established communication channels. We will manually reset the counters for you.

Flash Payments uses webhooks to notify your application when a transaction event happens in your account. This includes status update of your withdrawal, clearing of the incoming deposit, and more.

With webhooks, you can subscribe to the events of interest to trigger a subsequent action within your integration.

There are two steps to begin using webhooks. Building a custom endpoint on your server and registering it via the settings.

Each time a transaction event happens, we will send a HTTP POST request to your endpoint(s) that are subscribed to that event. The payload with event data is in the JSON format and can be used immediately. Every webhook endpoint must acknowledge the request, and as we strongly advise, verify the webhook signature.

Acknowledging request

To validate BSB, BIC (aka SWIFT code) or IBAN use the bankInfo query.

The below sample queries will return null if the BSB, BIC, IBAN is not found.

Validate BSB

Please verify that you have all the required data to initiate a successful payment transfer.

The response above means that if you want to send euros to Austria (AT) then you'd need a BIC (aka SWIFT) code and an IBAN.

There are two places an RFI call can report a problem: the code field on the mutation reply payload, and the top-level GraphQL errors array.

Returned in the code field of AnswerRfiQuestionReply / DeclineRfiReply:

A Request for Information (RFI) is a compliance request raised by Flash Payments against deposits, withdrawals, or payments that require additional information before they can be released. RFIs are created on our side when a compliance review flags certain transactions — you cannot create RFIs via the API.

Each RFI carries a list of questions and a response deadline. There are two ways to respond:

• Via the API (this section) — receive a webhook, , n with text or documents, or if you cannot comply.

Most common RFI status transitions follow one of these paths.

Happy path

PENDING → ASSESSING → CLOSED

1. It starts when our compliance review flags one of your transactions. An RFI is created with a list of questions and a response deadline. Status PENDING