Execute a transaction with a valid quote so NadaPay can initiate funds movement using the details you already prepared.

⏱️
Time to integrate: Most teams can connect transaction execution in under 10 minutes after quote generation, funding checks, and destination validation are already working.

What this endpoint does

Use this endpoint to finalize and initiate a transaction using a valid quote.

This is the step where your integration moves from preparation to execution. In most flows, you call this endpoint only after the source account, beneficiary, payout destination, and pricing inputs have already been validated.

When to call this endpoint

Call this endpoint when you need to:

initiate funds movement using a valid quote
complete a payout flow after all pre-execution checks are finished
trigger the transaction your application has already prepared and reviewed

This endpoint should come after account validation, beneficiary setup, payout destination validation, and quote generation.

Why execution is a separate step

Separating quote generation from execution helps your team:

validate inputs before moving funds
support internal approval or maker-checker workflows
reduce accidental execution with incomplete transaction data
log a clear transition from prepared transaction to initiated transaction

For enterprise teams, this separation is important for control design, auditability, and operational review.

Authentication

Send your API key in the x-api-key header on every request.

Item	Value
Authentication method	API key
Required header	`x-api-key`
Rate limit scope	Per API key

Recommended workflow

Use this endpoint in the core transaction sequence:

Fetch organization accounts.
Check verification status.
Create a beneficiary.
Add a beneficiary account.
Resolve bank account details if required.
Generate a quote.
Execute the transaction.

What to verify before execution

Before calling this endpoint, confirm all preconditions are satisfied.

At minimum, verify:

the quote was generated successfully
the quote ID you are using belongs to the intended transaction
the source account is correct and sufficiently funded
the beneficiary and payout destination are correct and usable
the environment matches the credentials and resources you are using
any internal approval or review step is complete

⚠️
Needs confirmation: Exact request fields, quote validity rules, transaction state model, and whether any additional execution-only fields are required should be confirmed in the API definition.

Validation guidance

Before executing a transaction, validate the request in your own system.

Recommended checks:

confirm the quote ID is the one you intend to execute
confirm the quote has not been replaced by a newer quote in your workflow
confirm the balance is still available at execution time
confirm the payout destination has not been changed or disabled since quote generation
confirm the transaction still meets your internal limits, policy checks, and approval rules

Execution is the wrong place to discover missing setup steps. Make this endpoint the final step, not the first place you validate business logic.

How to use the response

After the transaction is initiated, store the returned transaction identifier and status details in your backend.

You will typically use the response to:

track the transaction lifecycle
reconcile internal records with NadaPay processing
display status to internal users or downstream systems
investigate failures, delays, or support cases

Recommended post-execution flow

If execution succeeds:

store the transaction ID and returned status
update your internal transaction record
monitor the transaction until it reaches a terminal business outcome

If execution fails:

capture the returned error details
determine whether the issue is authentication, validation, funding, or transaction state
correct the root cause before retrying

Common use cases

Finalize a payout after quote approval

Generate the quote, complete any required review, then execute the transaction when the team is ready to move funds.

Trigger an operator-reviewed payment

Use this endpoint after an internal operator, treasury team, or compliance process approves the quote and destination.

Launch an automated payout workflow

Use this endpoint from a backend service after all upstream checks have completed successfully and the transaction is approved for execution.

Production notes

Before using this endpoint in production:

Restrict who or what can execute transactions.
Require source account, destination, and quote checks before execution.
Log every execution attempt, including failures.
Monitor initiated transactions until your business process considers them complete.
Define an internal escalation path for failed or delayed transactions.

This endpoint should be treated as a controlled funds movement action, not a generic API write.

Common failure cases

Authentication fails

Check these items first:

the x-api-key header is present
the API key belongs to the intended environment
the base URL is correct

The quote is invalid or unusable

If the execution request fails because of the quote:

confirm the quote ID is correct
confirm the quote still matches the intended transaction
generate a new quote if your workflow no longer trusts the old one

Insufficient funds or account readiness issues

If the transaction cannot proceed:

confirm the source account has sufficient balance
confirm the correct source account was selected
verify the funding currency matches the intended flow

Destination or validation issues

If the transaction fails because the destination is not usable:

recheck beneficiary and beneficiary account details
rerun bank account resolution where applicable
verify currency, network, provider, and corridor compatibility

Execution is accepted but the transaction does not complete as expected

Initiating a transaction does not always mean the business outcome is final yet.

Next check:

returned transaction status details
downstream status updates or webhook events if configured
internal monitoring and reconciliation records

⚠️
Needs confirmation: Exact execution response fields, transaction statuses, webhook event model, terminal states, and retry safety guidance should be confirmed from the API schema and backend behavior.

Enterprise implementation notes

Access control

Restrict transaction execution to trusted backend services or approved operators. Use internal approval controls where required.

Auditability

Record:

transaction ID
quote ID
source account ID
beneficiary or destination reference
initiating service or user
execution timestamp
returned status

Monitoring

Track:

execution attempts
failed executions
delayed transaction outcomes
high-value transactions
repeated errors by API key or source account

Operational controls

Define who can:

approve execution
pause transaction traffic
investigate failed or delayed payouts
escalate issues to NadaPay support

Troubleshooting checklist

Use this checklist if transaction execution is blocking your flow:

Confirm authentication with x-api-key.
Confirm the quote ID is correct and still trusted.
Confirm the source account is funded.
Confirm the beneficiary and payout destination are ready.
Confirm the environment is correct.
Store the returned transaction ID and status for follow-up.

Recommended next endpoints

After you execute a transaction, continue with:

If you need to revisit earlier steps, continue with:

Related pages

Generate Quote

Create and store the quote before you execute the transaction.

Get Currency Balance

Confirm the source account has enough balance before execution.

Going Live

Review production controls, funding readiness, monitoring, and launch ownership before moving live funds.