Bank transfers, USDC payments and order tracking

Use the public order reference exactly as shown in your secure instructions. It lets us securely match your transfer to your order.

Timing depends on banking hours, blockchain conditions, required checks, and whether more information is needed. Any displayed time is an estimate, not a guarantee.

You can request a limited status view with the public order reference and relevant wallet. Full details still require an email code.

Do not send a second payment. Open a support ticket with your order reference. Recovery is not guaranteed and may involve additional cost.

The public order flow allows only one unfinished order from the same client connection. Resume or cancel the current unfunded order before creating another. This reduces the risk of confusing instructions or transfer evidence between orders.

They appear inside the verified secure order when payment is allowed. Reopen the order through Track order and use the current details there. Do not treat an email, screenshot, previous order, or bank beneficiary saved elsewhere as the source of truth.

They can if the current service configuration uses the same instructions for both currencies. Always follow the exact currency-specific instructions shown in your order, even when some account fields look identical.

Use a bank account you are authorized to use and provide complete, accurate beneficiary information. Third-party funds or an unexplained name mismatch can trigger additional checks, a hold, refusal, or a permitted return. Disclose relevant circumstances through the secure portal.

Do not send the payment again. Open a Support ticket for the correct order, explain the reference used, and attach a non-sensitive transfer receipt if needed. Matching may take longer and can require additional verification.

A bank’s sent status does not prove settlement to the receiving account. Banking cut-offs, intermediary processing, weekends, reviews, recalls, or deductions can delay matching and confirmation. Keep your receipt and follow the secure order status; do not pay twice.

Yes. Bank operating hours, cut-offs, weekends, intermediary banks, compliance checks, and provider outages can delay receipt or payout. Any timing shown by the site is an estimate and does not guarantee completion on a particular day.

No. Do not send bank funds or USDC after an order is expired, cancelled, or rejected, and never reuse its instructions. Create a new quote only after the previous order is terminal, or contact Support if a transfer was already sent.

No. Once a real order is created and a public reference is displayed, it remains persistent on the server. Return through Track order with the reference and relevant wallet, then verify the order email when you need secure details.

Enter the public order reference and the relevant wallet address exactly. Both must match, and the public search deliberately does not reveal which value was incorrect. A matching result remains masked until the order email is verified.

Statuses can cover waiting for bank transfer or USDC, a transfer seen but awaiting confirmations, identity or wallet verification, additional information, review, preparing your transfer, payout in progress, completion, hold, expiry, cancellation, rejection, refund, or recovery review. The secure order explains the current next action.

Open the secure order through Track order and use Cancel order while it is still unfunded and marked cancellable. Confirm the cancellation there. Open verification requests and reserved Buy capacity associated with an eligible unfunded order are then closed or released.

Customer cancellation stops once an inbound transfer is confirmed or a Sell transaction is independently observed, or when the order has otherwise reached a non-cancellable state. Do not attempt a second action; contact Support so completion, return, or another permitted resolution can be assessed.

The order’s displayed pricing window has ended. Do not send funds using its old terms or instructions. A late transfer does not automatically keep the former Sell rate and may require a new calculation, return, recovery review, or another resolution.

Check the order email and any confirmation you saved. Do not guess references or create a duplicate funded order. If you still cannot find it, verify the same email in Support and provide non-sensitive context that can help locate the order.

Status changes depend on independent bank or blockchain evidence and any open verification review. Refresh the secure order after a reasonable interval. Do not duplicate a payment; if evidence and status remain inconsistent, open Support with the reference and receipt or transaction hash.

The USDC payout goes to the Ethereum destination recorded and confirmed for that Buy order. Completion is shown only after the required incoming bank transfer, outgoing blockchain payout, and any required checks are confirmed.

The EUR or USD payout is sent to the exact bank beneficiary confirmed for the Sell order. Recheck those details before creating the order. Once an outgoing bank transfer is confirmed, changing or recalling it may not be possible.

Preparing your transfer means the recorded inbound transfer and required checks permit preparation of the outgoing leg. Payout in progress means that outgoing transfer is being processed. Neither label by itself proves final receipt; wait for Completed and verify the bank or blockchain record.

You can ask Support, but cancellation is no longer automatic after fiat or USDC is received or independently observed. The service must assess whether completion, return, hold, or another resolution is lawful and operationally possible.

A permitted return is sent only to a verified originating or otherwise approved destination. Extra identity, bank, wallet-control, or transaction evidence may be required before release; Support cannot redirect funds merely because a new destination is requested in a message.

Refund timing depends on bank or blockchain processing, verification, and the chosen resolution, so it is not guaranteed. Permitted bank, network, recovery, and third-party costs may be deducted only where disclosed and lawful; the secure order or Support provides the case-specific status.

No. Recovery may be technically impossible, legally restricted, insecure, or more expensive than the assets. If an attempt is possible, it may require additional identity, proof of wallet control, time, and a disclosed recovery charge. Contact Support once and do not send more funds.

Do not send any further payment and do not try to assign the same evidence to another order. Open one Support ticket with the order reference and both bank receipts or transaction hashes. The extra transfer requires review and is not automatically credited or returned.

A confirmed blockchain payout is generally irreversible, and a completed bank payout may not be recallable. Verify every destination before confirming the order. If the destination is wrong or compromised, stop immediately and contact Support before the payout stage whenever possible.

Keep a receipt showing the transfer date, currency, amount, sender account in safely masked form, beneficiary details, and complete reference. Store it securely. Upload it only through an authorized Support or verification request and hide unrelated transactions where appropriate.

Sent means the bank accepted or released your instruction, not that cleared funds were received and matched. Bank routing, cut-offs, weekends, intermediaries, reference issues, and reviews can add time. Keep the receipt and monitor the secure order rather than sending again.

A reversed or recalled transfer may no longer provide settled funds for the order. Do not assume the Buy can continue or send a replacement automatically. Track the order and contact Support with the bank reference and non-sensitive evidence so the payment state can be reviewed.

Check the bank’s reason and the order status. A return means the original payment should not be treated as successfully funding the order. Do not resend to saved details without current instructions; contact Support if the order remains open or the reason is unclear.

When an outbound blockchain transfer is genuinely sent and recorded, the secure order can provide its transaction reference or explorer context. A hash is evidence of a transaction, not by itself proof that the correct wallet credited it. Verify network, token contract, destination, amount, and confirmation state.

Keep the payment receipt showing every field and track the order. If it is not matched, provide the order reference and receipt to Support rather than sending another transfer.

Save evidence of the exact reference that the bank transmitted and monitor the order. If matching is delayed, send that evidence and the full order reference through the secure Support channel.

Keep the receipt, but be prepared to provide another bank document that links the sending account to you if requested. Hide unrelated balances or transactions while leaving relevant payment details visible.

Show the transfer status, amount, currency, date, sender account identifier, beneficiary, and transmitted reference where available. Crop unrelated content, but do not crop the fields needed to match the order.

A protected file may not be reviewable or pass attachment checks. Export a safe readable copy that contains the relevant transfer evidence and does not require sharing a banking password.

A recall request does not confirm that funds were returned. Track the bank request and the order together, and notify Support before taking another payment action because the transfer may still arrive.

Banks can display initiation, booking, execution, and value dates separately. The order updates from the payment events it can verify, so keep the full receipt if those dates could explain a delay.

A cross-border payment may involve intermediary banks or additional information. Follow the exact routing details shown and retain the full trace or receipt if the payment does not arrive as expected.

Choose the option that delivers the exact instructed amount to the beneficiary under your bank’s rules. If labels such as shared, sender, or beneficiary are unclear, ask the bank before authorizing the payment.

Banks commonly format IBANs with or without spaces. Compare the complete sequence of letters and digits after formatting, and stop if any actual character differs from the secure instructions.

Use only a code supplied in the secure payment instructions or confirmed through Support. Do not look up and guess a code from the beneficiary name because different branches or currencies may route differently.

Compare the bank’s resolved beneficiary details with the secure instructions. A display abbreviation may be harmless, but a materially different person or organization is a reason to stop and verify before paying.

Answer your bank through its official channel and do not claim the payment has arrived while it remains paused. Track the order deadline and contact Support if the bank review will outlast it.

A status can change when new payment, blockchain, bank, or verification information needs review. Read the latest action message and avoid repeating the transfer solely because an earlier status changed.

Open the secure order page directly and refresh it; an email records the state when it was sent and can arrive late. If the conflict remains, give Support the email time and current status.

Browsers can pause work in inactive or sleeping tabs. Bring the secure page to the foreground and refresh it once; do not infer a failed payment from a frozen progress indicator.

Use each value only where its instructions place it. The public order reference used for tracking may be presented differently from a bank payment field, so copy from the relevant secure section.

A transaction hash identifies an on-chain event, while the order reference identifies the service request. Keep both and use the tracking credentials requested by the secure order lookup.

Do not cancel or resend blindly. Preserve both bank identifiers, track the associated order, and tell Support which transfer completed and which remains pending so each can be reconciled.

Check the destination account and currency first. Then ask Support for the available payout reference or trace details and give those to the receiving bank; do not expose banking credentials.

Do not start a second order while the first payment outcome is unknown. Keep the initiation evidence, monitor the original order, and contact Support if it expires without recognizing the payment.

They may use different time zones and event types, such as initiation, broadcast, confirmation, or booking. Provide the timestamp together with its source and zone when asking Support to compare events.

Cancellation can stop being available after the order reaches a funding or processing stage. Read the current status and contact Support if you need help; do not try to cancel by manipulating the page or resending data.

There is no universal time because propagation, provider health, gas, nonce order, and congestion vary. First verify that the hash exists on the correct network and shows the expected transfer; then follow the secure order and escalate if its guidance says to.

Once the site confirms creation and presents a public order reference, retain that reference and treat the order as active until its secure status becomes terminal. A quote preview alone is not a created order.

Yes. Return through Track order with the original reference and verify the order email again when asked. The secure page shows the current active step; do not open a replacement order merely because a document or verification form was interrupted.

Search the verified email and any secure record created at confirmation. If it remains unavailable, contact Support from that email with non-secret context such as direction, approximate date, currency, and payment evidence.

The order has not yet confirmed the required inbound bank transfer or USDC transfer. Follow only its current secure instructions and do not pay twice because your bank or wallet shows an earlier attempt as pending.

Processing has paused pending a stated check, information request, provider condition, or review. Read the secure timeline for the action assigned to you; creating another order does not remove the hold.

The order needs a customer step before it can progress, such as verification, corrected information, or secure confirmation. Open the authenticated order directly, check the deadline, and complete only the listed request.

The order cannot proceed under its current details or requirements. Do not fund it or reuse its instructions. Review any customer-visible reason and use Support if a payment was already sent or you need to challenge an apparent error.

Its quote and payment instructions are no longer valid. Do not pay it after expiry. Once the status is terminal and no payment attempt exists, you can request a new quote subject to current limits and availability.

The order has been closed and its instructions must not be used. Cancellation does not reverse a bank or blockchain transfer already sent, so contact Support immediately if payment may still arrive.

The service has recorded the order’s payout step as completed. Check the destination wallet or bank account independently and retain the records. If the credited result is absent or differs, contact Support with precise evidence.

One active customer journey reduces mixed references, addresses, payments, and evidence. Resume the existing order or cancel it while eligible; do not open parallel sessions to bypass the active-order message.

Avoid simultaneous edits or submissions. One device may show stale state and cause duplicate actions. Use the newest secure status on one trusted device, except for an explicit KYC phone handoff.

Customer cancellation is intended for eligible unfunded stages. Once an inbound transfer is observed, confirmed, or payout processing begins, closing the order could conflict with funds already moving and requires a controlled resolution.

Do not rely on inactivity as cancellation. A funded or observed order remains subject to its processing and resolution states even if you stop visiting the page. Track it and respond to any secure request.

Occasional refresh is enough if live updates appear delayed. Repeated rapid requests do not accelerate banking, blockchain, verification, or payout processing and can trigger temporary access protection.

A payout completes the intended exchange to the order’s destination. A refund or return sends eligible received value back after an order cannot complete, subject to verification, route, costs, and applicable terms.

A permitted return generally follows the verified original funding source or another destination allowed by the applicable process. It is not an opportunity to redirect value to an unrelated wallet, person, or bank account.

Do not assume so. Changes can create ownership, security, and compliance risk and may require fresh verification or be unavailable. Use only the secure resolution offered for the original order.

Network, bank, intermediary, conversion, investigation, or recovery costs may apply under the disclosed terms and available route. The secure resolution should explain known treatment; do not assume the original gross amount can always be returned.

A return can depend on verification, asset accessibility, blockchain conditions, bank cut-offs, correspondents, and receiving-bank posting. Any estimate is conditional until the permitted return is actually issued and received.

The banking return must be received and reconciled before another permitted resolution can be assessed. Keep the order reference, obtain the rejection reason from your bank, and do not submit replacement details outside the secure process.

No. Recovery depends on whether the destination is technically accessible on that network, the token and address behavior, security, law, cost, and policy. Stop sending and provide the exact hash and network to Support.

No. The order cannot treat another token as supported USDC or automatically trade it. Recovery, if technically and legally possible, is a separate assessment and may cost more than the asset.

A public hash shows movement but not necessarily who is entitled to request a return. A secure ownership check helps prevent someone else from redirecting value they observed on the public blockchain.

The valid order transfer and extra transfer must be identified by separate hashes. The extra value is not automatically another order or payout; it requires verification and an available return or recovery process.

The blockchain record is immutable and the confirmed quote was based on specific values. Editing the display would not change what moved on-chain. The mismatch needs a documented completion, return, or other permitted resolution.

An approved return is being prepared or has entered its payment route, but receipt is not yet complete. Keep the original order open for trace information and do not request conflicting destination changes through another ticket.

It can happen if external network, bank, conversion, or recovery costs apply or only part is technically accessible. No recovery amount should be assumed until the specific transaction has been assessed and a secure resolution is offered.

Provide the order reference, expected currency and amount, beneficiary account ending, relevant date range, and a redacted statement showing the missing credit. Support may provide or request a bank trace identifier when available.

No card-style chargeback exists for a finalized blockchain transfer. If the order outcome is disputed, use the formal Support or complaint process with the hash and records rather than attempting an unrelated reversal claim.

Not necessarily. A reservation or hold can precede execution and may still be released. Check the bank’s actual transfer status and keep the order open; receipt is confirmed through the order workflow, not by the reduced available balance alone.

No. The bank ID identifies the transfer in the banking system, while the order reference identifies your A-PFI order. Keep both because Support may need them to trace and match a payment.

It is a rail-specific bank tracking identifier, not your order reference. Keep it with the receipt when the bank provides one because it can help the banks investigate a delayed or missing transfer.

The original preserves identifiers, dates, currency, status, and document context that an edited image may remove. Keep it privately and send only the relevant permitted copy requested by Support, with unrelated sensitive details redacted.

No. A sensitive access link or verification session can expire while the persistent order remains. Start from the official tracking page, enter the correct order details, and complete the new purpose-specific email verification.

Each Buy remains separate even when the email and amount match. The transfer must be traced against the order-specific reference and current bank instructions you actually used. Track that reference, leave the other order unfunded or cancel it if eligible, and do not claim that both were paid.

No. First compare the bank receipt with the reference, amount, currency, and instructions of the order you funded, then track that exact order. Opening a different order does not move the payment. Do not send a second transfer while the first one is being located.

No. A refund or payment investigation must identify the order and transfer that were actually funded. An unfunded order has no payment of its own to refund, and using its reference does not reassign another order’s money. Open the funded order or contact authenticated Support with both references and the genuine receipt.

No. A Buy payment is an exact, order-specific transfer and cannot be allocated across two references. Use one current set of instructions for one order only. If one transfer was intended to cover two orders, do not send an adjustment or a second payment until authenticated Support reviews the actual receipt.

If the bank has not executed the transfer, stop and rebuild it from one authenticated order page. If it has executed, do not edit either order or send another transfer to compensate. Keep the bank receipt and contact authenticated Support with both order references so the mixed details can be investigated.

Do not alter the receipt or upload it repeatedly. Reply through the authenticated Support channel, identify the ticket and both order references, and state which order the original transfer belongs to. Correcting the context does not itself move or confirm funds; the payment still has to be traced from its real banking details.

Yes, but only if the second order is still eligible for cancellation and no payment used its reference or instructions. Compare both references with your receipt before acting. Cancelling the unfunded duplicate does not serve as a cancellation or refund request for the separately funded order.

An email address can help authenticate access, but it does not combine separate orders. Each order keeps its own reference, instructions, payment evidence, and status. Track the reference shown on the matching receipt and do not reuse its payment evidence to mark another order as funded.

A timeout does not show whether the bank executed the instruction. Reopen the bank through its official app or site and look for a final status, transaction identifier, amount, and reference before doing anything else. Do not repeat the transfer merely because the confirmation page disappeared.

Not until the bank confirms what happened to the first instruction. Keep the order reference and check the bank’s official activity or contact the bank when service returns. If the result remains unclear near the order deadline, contact authenticated Support; a bank outage does not make a duplicate payment safe.

No. A declined instruction with no debit has not funded the order. Resolve the reason with your bank, then return to the same order and use only its current instructions if it is still eligible for payment. Do not create a refund request for funds that never left the account.

Bank labels can change while a transfer is being checked, recalled, or finally posted. The earlier label is not proof that the beneficiary received final funds. Follow the bank’s current status, retain both records, and do not resend while the bank or authenticated Support is investigating.

Not necessarily. One entry may be an authorization, duplicate display, or separate instruction, and the order page cannot resolve your bank ledger. Ask the bank which identifiers can actually execute. Do not create or fund another order; if both entries settle, keep both receipts and contact authenticated Support.

An estimated arrival is not confirmation of final receipt. Check whether the bank shows the transfer as executed, returned, held, or still processing, and obtain its trace identifier when available. If the estimate has passed, send the order reference and bank trace through authenticated Support instead of paying again.

Do not assume that the transfer completed or was harmlessly cancelled. Search the bank’s pending, posted, rejected, and returned sections, then ask the bank for the instruction’s final status and identifier. Keep the order unfunded in your own records until actual execution or receipt is established.

No. Stop before authorizing the transfer. Refresh the authenticated order page and compare every bank field without guessing or substituting another account. If the same warning remains, contact authenticated Support with the order reference and the bank’s exact error; never use replacement details received informally.

Do not approve it based on the beneficiary name alone. Compare the country and every routing field with the current authenticated instructions, because banks and payment providers can present routing information differently. If any value conflicts or is absent, stop and ask authenticated Support before sending.

A screenshot can help identify a transfer, but it does not by itself establish final, matching receipt. The payment still has to be traced against the order reference and banking records. Provide an original receipt or trace when requested, and never edit a pending label to make it appear completed.

Keep the bank’s case number, transfer identifier, trace number, dates, amount, currency, beneficiary details, and any final written finding. Send only the relevant permitted documents through authenticated Support with the correct order reference. A case opening is not confirmation that the funds arrived or will be returned.

Do not send another transfer. Confirm that the trace has the exact amount, currency, beneficiary, execution date, and order reference, then share the official trace through authenticated Support. A bank’s Delivered label is useful evidence, but the order still needs the incoming payment to be matched and verified.

No. A replacement can create an accidental duplicate while the first transfer is still unresolved. Keep the original order open when possible, preserve the receipt and bank case details, and wait for a clear outcome or purpose-specific instruction from authenticated Support before taking any new payment action.

Yes, but keep the original rather than revealing or inventing hidden digits. The receipt should still show as much as the bank provides, including the transfer identifier, amount, currency, date, status, sender, and order reference. Support may ask for an official trace if the masked receipt cannot distinguish the destination.

You may redact unrelated transactions and balances, but do not change the payment itself or hide fields needed to trace it. Preserve the amount, currency, date, status, sender, beneficiary, order reference, and bank identifiers. Keep the unedited original privately in case a secure follow-up requires it.

Keep both and provide the bank’s latest official version, clearly noting that it replaces or corrects the earlier receipt. Do not alter either document yourself. If the versions disagree on the amount, currency, beneficiary, reference, or final status, ask the bank to explain the correction and include that explanation with the order reference.

Do not spend it, treat it as a completed Sell, or send it back using details from an email or caller. Compare it with your real order records, ask your bank for the credit’s official identifiers, and contact authenticated Support. An unfamiliar description alone does not prove who sent the funds or why.

Do not act on return instructions delivered by an unsolicited email, message, or call. Keep the funds untouched, verify the situation with your bank, and open authenticated Support from the official site using the actual Sell reference. Never substitute a new return destination without verified, case-specific instructions.

A receiving bank can restrict availability after a payout is sent or credited. Check the authenticated order for its current status and ask the bank what its hold means; the site cannot release a bank-imposed restriction. Keep the order and bank references, and do not create another Sell to replace held funds.

The booking date records when the bank posted the entry, while the value date can affect when that bank treats the funds as effective or available. These labels do not change the Sell order itself. Ask the bank how they apply to your account and use the authenticated order page for the payout status.

Do not spend or independently return the apparent duplicate. Ask the bank whether both entries are final credits or a display correction, then contact authenticated Support with the Sell reference and both bank identifiers. Ignore any unsolicited message that supplies a different account for returning money.

Refresh the authenticated order and confirm that the bank credit matches the same Sell amount, currency, and reference context. Do not create another order or return the credit because of the display mismatch. If the status remains behind, report both records to authenticated Support so they can be reconciled.