Selling USDC for a EUR or USD bank payout

Choose Sell and a EUR or USD payout amount, review the exact USDC requirement and expiry, enter the self-controlled Ethereum sending wallet and payout bank details, verify your email, and accept the policies. Then send one new exact transfer to that order’s dedicated address and submit its transaction hash.

The exact sending wallet is part of the transfer match and may need an ownership authorization. A custodial platform can broadcast from a different wallet than the address you entered, so its transfer may not match the order.

A dedicated receiving address separates simultaneous transfers and becomes permanently associated with that Sell order. Send only to the address shown in the current secure order; never reuse an address from an older, cancelled, expired, or different order.

The amount alone never identifies a Sell payment. Matching uses the order’s dedicated receiving address, the exact saved sending wallet, the new transaction hash, token contract, network, and amount. A transaction hash cannot be assigned to a different order.

No. Make a new native Ethereum USDC transfer after the order is created, from the saved wallet to that order’s dedicated address. An older transaction, another wallet, or another order’s address cannot be used as payment.

The Ethereum transaction hash is the 0x-prefixed identifier containing 64 hexadecimal characters returned by the sending wallet after broadcast. Copy the new hash into the secure order so the transfer can be checked independently; never substitute a wallet address or an older hash.

A broadcast or mined transfer can be detected before it reaches the configured confirmation requirement. Keep the order open and wait for the secure status to update. Do not send the transfer again merely because confirmations are still pending.

Do not withdraw directly from Crypto.com, another exchange, or any custodial platform. Its actual blockchain sender can differ from the address you entered, and batched or multi-recipient withdrawals are not supported. Move funds to a self-controlled wallet first if appropriate for you.

No. Send one exact native Ethereum USDC transfer per order. Split, batched, or multi-recipient transactions are not supported and can require manual review; if you already made one, stop and contact Support rather than sending more.

Confirm the exact beneficiary name and account that should receive the payout. EUR requires an IBAN. USD accepts an IBAN or both an account number and routing number; BIC/SWIFT and bank country can be supplied where applicable.

A token approval authorizes a contract but does not necessarily transfer USDC to the order address. Check the explorer for a USDC transfer to the exact recipient and submit the hash for that transfer.

A failed transaction does not deliver the ordered USDC. Do not present it as payment; if the order is still valid, create the required successful transfer and use its distinct hash.

Do not mark an order as funded based only on a wallet’s earlier pending screen. Confirm that the transaction exists on the correct network and has not been dropped or replaced before providing evidence.

A replacement can supersede the original transaction. Use the hash that ultimately carries the successful USDC transfer to the dedicated address, and give Support both hashes if the order shows the old one.

An Ethereum transfer normally also needs the network’s gas asset in the sending wallet. Check the wallet’s gas requirement and network before attempting the Sell transfer; do not reduce the ordered USDC amount to cover gas.

No. The wallet’s network fee and the order’s USDC amount are separate values. Send the exact USDC amount shown and ensure the wallet has the separate asset needed to pay network fees.

Do not create another order to account for the difference. Keep the transaction hash and contact Support so the single overpayment can be reviewed against its original dedicated address.

Do not send a second transaction unless Support explicitly tells you how to proceed for that order. Preserve the first hash and ask for instructions, because multiple transfers can complicate matching and pricing.

Do not reuse that transaction for the new order or send again without guidance. Record both order references and the transaction hash, then contact Support for a recovery review.

No. Cancellation means you should stop using that order’s payment instructions. If a transfer was broadcast around the same time, keep its hash and contact Support instead of creating a conflicting payment.

Scanning reduces typing but does not replace verification. Compare the recipient shown on the wallet’s final confirmation with the full address in the secure order instructions before approving.

No. Similar-looking history entries can be misleading. Copy the dedicated address directly from the secure order, verify the full value, and do not choose a recipient merely because its first and last characters match.

A hash on another network does not prove that native USDC reached the order address on the required network. Contact Support with the hash and do not claim a second transaction is the same payment.

Copied text can include spaces, line breaks, labels, or an explorer URL. Paste only the transaction hash in the requested field and compare its beginning and end with the wallet record.

Do not use that unrelated hash as evidence. Return to the order’s available evidence step or contact Support with the order reference, the incorrect hash, and the correct transfer hash.

Make sure every required signer approves before the order deadline and that the final on-chain transfer sends the exact token and amount directly to the dedicated address. A proposal alone is not payment.

No. Send one direct native Ethereum USDC transfer from the recorded wallet to the dedicated address. Batched or multi-recipient transactions are not supported; if one was already sent, do not resend—contact Support with the transaction hash.

A bridge operation may use intermediate contracts, a different token, or a delayed destination transfer. Send only through the direct method and network specified by the order unless Support confirms otherwise beforehand.

Keep the original broadcast hash and let the order status reflect the review. Do not replace, resend, or create a second order unless instructed, because timing and pricing need to be assessed against the recorded transfer.

Contact Support immediately with the order reference and do not submit substitute bank details through an unrelated order. The payout destination change, if possible, requires a secure review.

A returned payout and the original USDC receipt are separate events. Track the order and give Support the bank’s rejection or return details so an appropriate payout resolution can be reviewed.

Resolve that before sending USDC whenever possible. Your bank might reject or convert the payout; if the order is already funded, contact Support rather than changing the expected currency yourself.

Do not silently replace the payout identity with a different name. Keep evidence of the account and name change, then contact Support so the order details can be reviewed securely before payout.

Confirm that you hold the supported native USDC in a wallet you control, can pay Ethereum network fees, and have accurate bank-beneficiary details. Review the amount, quote window, and instructions before confirming the order.

Choose an available payout currency in the Sell form before requesting the quote. Use bank details able to receive that currency, and do not assume your bank will convert an unsupported incoming payment without fees or delay.

The Sell form uses the requested EUR or USD payout to calculate the exact USDC requirement under the displayed quote. Review both sides carefully because the blockchain transfer must match the order’s stated USDC amount.

Check the USDC to send, payout currency and amount, rate, disclosed charges, network-fee treatment, quote deadline, and receiving bank details. Stop before confirming if any field differs from what you intended.

The confirmation view and secure order show the applicable deadline. Treat the time displayed for that order as authoritative and avoid relying on a screenshot, email, or deadline from a previous quote.

Use the deadline exactly as rendered in the secure order, including any time-zone indication. If your device clock or locale appears inconsistent, refresh the page and confirm the displayed deadline before sending USDC.

Copy it directly from the current secure order and compare the beginning and end after pasting it into your wallet. Do not retype it, use a shortened display, or copy an address from a message or earlier order.

No. A Sell order expects one new transfer for the exact USDC amount shown. A separate test creates an unmatched or partial transfer; verify the network, token, address, and amount before making the single ordered transfer.

An Ethereum token transfer also needs the network’s native asset to pay gas. Your wallet may hold enough USDC but insufficient ETH for the fee. Follow your wallet’s fee guidance without changing the ordered USDC amount.

Enter the exact USDC amount from the order rather than relying on Max. Wallet behavior differs, and using the full native-asset balance may leave too little ETH for gas even when the USDC amount appears correct.

No. Copy the amount with every displayed decimal place. Rounding up or down creates an amount mismatch and can delay processing or require a separate resolution.

Open the wallet’s detailed send view or transaction preview to confirm the underlying amount. If the wallet cannot enter the exact displayed value, do not approximate it; use a compatible self-controlled wallet or ask Support before sending.

Yes. Use the self-controlled sending address recorded for that order. A transfer whose on-chain sender differs can fail the order’s matching and wallet-control checks, even if you initiated it through another service.

A hardware wallet can be suitable when it sends native USDC directly from the address recorded in the order on the supported network. Verify the transaction on the hardware device itself before approving it.

The transfer must come directly from the exact wallet recorded in the order and contain one supported native USDC transfer to the dedicated address for the exact amount. Relayed, batched, or multi-recipient transactions are not supported; use a compatible self-controlled wallet instead.

A multisignature wallet may require additional compatibility or ownership review because the transaction can be executed by a contract. Confirm support before creating or funding the order and make sure all signers understand the exact destination and amount.

Follow the order form’s displayed steps. Entering an address does not authorize spending, and you should never approve an unrelated token allowance or share a recovery phrase merely to create or track an order.

The displayed step asks you to review and complete a wallet authorization without transferring funds. It records your response for the order and may be followed by review; it does not by itself establish final ownership or AML approval. Read the exact message and domain, and never disclose a private key or approve token spending.

The order may remain unable to pass the required wallet check. Do not send USDC while a required verification is incomplete; return to the secure order for the available next step or contact Support.

Not necessarily. Look for a transaction hash and check it independently on the supported network. Do not resubmit until you know whether the wallet broadcast a transaction, because repeated attempts can create duplicate transfers.

A failed on-chain transaction normally transfers no USDC, although the network fee may still be spent. Confirm the failure using its hash, then check the order deadline and current instructions before deciding whether a new transaction is still permitted.

Wallets can replace a pending transaction when it is sped up or cancelled. Submit the hash of the transaction that actually confirms the USDC transfer, and tell Support if the secure order already contains the superseded hash.

Use only a standard speed-up feature from the same wallet and nonce if you understand it. It should preserve the exact token, recipient, and amount; verify the final hash and avoid creating a separate second transfer.

Some wallets can attempt a same-nonce replacement before confirmation, but success is not assured. An order cancellation does not cancel a blockchain transaction. Check both statuses and contact Support if the transfer may still confirm.

Open the completed send activity in the wallet and copy its transaction ID, usually a 0x-prefixed 32-byte hash. Confirm that it shows the exact USDC transfer to the order address, not an approval, wallet address, or unrelated transaction.

An approval only grants another address permission to spend tokens; it does not transfer USDC to the order’s deposit address. Provide the hash for the actual transfer and do not grant new allowances unless your own trusted wallet flow requires them.

One blockchain transaction can evidence only its actual transfer and cannot fund two orders. Recheck that you copied the new transfer created for this order; if you believe the warning is wrong, stop and send the hash and both references to Support.

The transaction may be unbroadcast, mistyped, or from a different network. Check the network selected in the sending wallet and use an explorer for the supported chain. Do not send another transfer until the first attempt is understood.

Submit the correct hash once and let the secure order update. Repeated submissions do not add confirmations. If you entered the wrong hash or a replacement occurred, use the available correction path or contact Support with the order reference.

Yes. A created order remains available through secure tracking even if the tab closes. Keep the reference and email access, then return later to review confirmations, verification requests, or payout progress.

Do not send again. Retrieve the transaction hash from your wallet, reopen Track order with the original reference and verified email, and submit or share the hash through the secure path available there.

Do not create or fund another order. Contact Support through an available channel with the public order reference and transaction hash. Additional verification may be needed before sensitive information or payout changes can be discussed.

No. Reject the wallet request and return to the secure order. Do not broadcast after the displayed deadline; a late transfer may no longer match the quote and can require review or return handling.

Do not assume broadcast alone satisfies the deadline. The order explains the relevant observation or confirmation condition. Allow time for wallet signing, network propagation, and congestion rather than waiting until the last moments.

Do not send anything else or create a conflicting claim. Track the original order and contact Support with its reference and transaction hash. The transfer must be assessed under the applicable terms; completion at the expired quote is not assured.

The order cannot treat a smaller transfer as the exact requested payment. Do not top it up with another transaction unless instructed through the secure order. Keep the hash and contact Support for the permitted resolution.

The excess is not automatically added to the quoted payout. Do not send another transaction or open a second order for the difference. Keep the hash and wait for the secure order or Support to explain the available handling.

Do not submit either transfer to another order. Record both hashes and contact Support from the email associated with the original order. One transfer may match the order; the other requires separate assessment and is not an automatic second sale.

Do not reuse the hash or send a compensating transfer. Contact Support immediately with both order references, the hash, amount, sender, and destination. Attribution or recovery may be restricted or impossible, especially after funds move on-chain.

A payout account may be subject to customer, ownership, duplication, and eligibility checks for each order. Never assume acceptance from an earlier order; enter the accurate beneficiary details and follow any verification shown.

Use only a beneficiary permitted by the order and applicable verification requirements. A third-party account can create ownership and compliance problems and may be rejected; do not enter another person’s details merely for convenience.

A joint account may require evidence that the verified customer is a named holder and that the account can receive the selected currency. Enter the beneficiary exactly as held by the bank and provide requested evidence through the secure portal.

Do not assume an individual order can use a company account. The customer type and beneficiary ownership must match the supported flow. Use personal details for an individual order or ask Support about business eligibility before funding.

Use the form accepted by your bank statement or account certificate. Do not invent an abbreviation. If the order field cannot represent the official name accurately, contact Support before sending USDC.

Enter the full IBAN from your bank document. The form may normalize spaces and letter case, but you must still compare every character before confirming. Formatting cleanup does not validate account ownership or payout eligibility.

Use the routing information your bank specifies for the incoming transfer type shown by the order. ACH and wire routing numbers can differ. If the order or bank document is unclear, confirm with your bank or Support before funding.

It can be required for particular international or correspondent-bank routes. Provide it when the form requests it, using an official bank document. Do not guess a branch code or copy one from an unrelated account.

Enter only the fields requested by the order. If your bank says an intermediary is mandatory but the form has no place for it, contact Support before sending USDC instead of placing extra instructions in an unrelated field.

Contact Support immediately and do not submit replacement details through ordinary messages. A beneficiary change may require renewed verification and may not be possible once payout processing has begun.

Do not fund the order. Use any permitted edit or cancellation path shown in the secure order; otherwise contact Support. Creating a correct new order is safer than relying on a note to override confirmed beneficiary details.

Contact Support immediately from the order’s verified email. Do not create another order or ask the bank to infer the destination. Whether details can be corrected depends on verification and how far payout processing has progressed.

A rejected transfer may return through banking channels after deductions or delay. Keep the order open for updates and provide any requested bank evidence. Do not change the beneficiary or send more USDC unless the secure order instructs you.

Your bank may apply its own conversion if the account does not hold the payout currency, potentially changing the credited amount and adding fees. The order covers the stated payout currency, not a downstream conversion chosen by the bank.

The descriptor can depend on the paying bank or provider and may not exactly match the website name. Match the amount, currency, date, and order reference where available; ask Support before treating an unfamiliar credit as unrelated.

No standard order should be assumed to support split payout. Use the single confirmed beneficiary presented in the order. If your needs differ, ask Support before creating or funding the order rather than supplying multiple accounts afterward.

Intermediary or receiving banks may deduct charges, or the bank may have converted currency. Compare the order and statement, then ask your bank for the transfer trace and fee details before opening a Support ticket with the evidence.

Bank alerts can be delayed or disabled. Check the account ledger and pending entries directly, verify the currency account, and allow for banking processing. If still absent, request a trace through Support with a redacted statement.

Completion can reflect that the payout was issued, while the receiving bank still processes or displays it. Banking cut-offs, correspondents, weekends, and local posting rules can affect when the credit becomes usable.

Keep the public order reference, quote summary, transaction hash, wallet receipt, status messages, and bank credit record. Store them securely and redact private information before sharing anything outside the secure portal.

No. Order records show transaction details but do not determine your tax basis, gain, loss, or reporting duty. Keep your own acquisition and disposal records and consult a qualified adviser for the rules that apply to you.

Use the public order reference to relate the quote, blockchain hash, support correspondence, and bank payout. Do not use a one-time code or sensitive access token as an accounting identifier.

Do not mix another person’s wallet, identity, email, or bank account into your order. The customer information and authority to use each account or wallet must match the supported flow. The other person should use their own eligible details.

Eligibility depends on the age and customer requirements displayed by the service and applicable terms. Do not use a parent’s or another person’s identity to bypass an eligibility check; contact Support if the requirements are unclear.

Update Support before funding if the recorded residence is no longer accurate. Availability, verification, and bank eligibility can depend on country. Do not select an old country simply to preserve a quote.

Service coverage can depend on law, sanctions, banking routes, verification capability, and operational availability. Do not use a VPN, false address, or third party to disguise your location; rely on the availability shown in the form.

Avoid parallel order forms. They can show different quotes or cause you to mix references and deposit addresses. Complete, cancel, or resume the active order in one tab before starting another permitted order.

Use a trusted personal device when possible. On a shared device, avoid saving codes or bank data, close the session, clear only your sensitive session information, and never leave the secure order visible to another user.

Do not recreate or fund it based only on email delivery. Check the on-screen reference and Track order, then inspect spam and mailbox filters. Contact Support if you cannot confirm whether an order exists.

A screenshot can help, but also store the reference as text in a secure place so every character remains readable. Never publish a screenshot containing personal details, bank information, access codes, or full secure links.

The secure order is presenting the funding instructions and awaiting the specified transfer, subject to its current deadline and checks. Re-read the exact address, token, network, amount, and sender before using your wallet.

It indicates that a candidate on-chain transfer has been observed, not that all confirmations and order checks are complete. Do not send again. Keep tracking the same order for confirmation or any mismatch notice.

The transfer is visible on the supported chain but has not yet reached the order’s required confidence level. Network progress, not repeated hash submission, adds confirmations. Wait and monitor the secure status.

Blockchain confirmation is only one part of processing. The order may still require identity, wallet, amount, beneficiary, source, or operational review. Respond only through the secure request and avoid opening duplicate orders.

It means the required inbound and review steps are complete enough for payout preparation. It does not mean the bank has credited you yet. Keep the beneficiary account open and monitor the order until payout is issued and received.

It indicates that the bank payout instruction was issued. The receiving bank may still need time to post the credit. Use the order’s available payment reference or trace details if a later bank inquiry is needed.

Use Cancel order while the secure order still shows it as unfunded and cancellable. Confirm the cancellation, then discard that order’s address and quote. Do not fund it after cancellation.

Do not assume so. A blockchain transfer may confirm even if the order page still offers an earlier state. Refresh and contact Support with the hash. Never cancel and then reuse the same transfer for another order.

Wait until the original order clearly shows a terminal cancelled state and confirm that no blockchain transaction was sent or remains pending. The new order will have its own quote, reference, deadline, amount, and deposit address.

Yes. The sending bank, receiving bank, correspondents, or currency-clearing system may observe different holidays. The order can progress operationally while the banking credit waits for the next processing window.

Blockchain activity can continue while bank rails have limited operating windows. Confirmation does not guarantee same-day bank credit. Follow the secure order and the receiving bank’s posting schedule.

Pause before funding if the address, token, network, amount, deadline, sender, beneficiary, verification state, or browser security looks wrong. A short delay before an irreversible transfer is safer than trying to repair an avoidable mismatch.

No. Signing prepares authorization, but the USDC transfer must be broadcast to Ethereum and receive a transaction hash before it can be observed. Do not submit a local signing identifier as payment evidence.

Not necessarily. A user-operation or bundler identifier can differ from the final Ethereum transaction hash, and smart-account execution may be batched or relayed. Direct Sell funding must be one native Ethereum USDC transfer from the recorded self-controlled wallet, so use a compatible direct transfer instead.

No. A relayer can make the on-chain sender differ from the wallet recorded on the order. Send exactly one direct native Ethereum USDC transfer from the recorded self-controlled wallet.

Do not assume an estimate extends the deadline. If you cannot make the required direct transfer under the displayed conditions, avoid sending to an expiring order and create a fresh Sell when you are ready.

No. A permit authorizes a later token action but does not itself transfer USDC to the deposit address. Use one ordinary direct transfer and submit its final Ethereum transaction hash.

The direct USDC transfer must come from the exact wallet recorded for the Sell order. Switching the active account does not update the order; return to the recorded address or contact Support before sending.

No. A valid message signature can demonstrate control of that address for the stated challenge, but it does not by itself establish legal identity, source of funds, transaction ownership in every context, or completion of required checks.

No. The challenge is tied to its displayed purpose and order context. Sign only the fresh message shown for the current Sell and never paste a signature from another order.

Confirm the official site, selected address, order reference or context, stated purpose, and that the wallet requests a message signature rather than a transaction or token approval. Reject anything unexpected.

No. Stop if a control check unexpectedly requests a token transfer, approval, contract call, or gas payment. Close the prompt and contact Support through the official site without sharing wallet secrets.

Reject it. Recheck the browser address and start again only from the official order page. A mismatched domain or unexplained application name can indicate that the wrong site or wallet connection is active.

Use the device’s supported detail or scroll view to verify the full recipient and exact USDC amount. Do not approve based only on the first and last characters shown by another screen.

Enter the exact USDC amount shown by the order and verify that the scanned recipient is identical. Never let the wallet’s Max button or a remembered value choose the amount.

Stop and recheck both the QR source and order. The current order’s exact USDC amount and dedicated address must agree with the wallet preview; do not send while any field differs.

Usually no. The gas limit is not the same as the amount ultimately charged, and setting it too low can make the transfer fail while still consuming gas. Use a reliable wallet estimate unless you understand the transaction fully.

The maximum is a cap for the transaction, while the actual fee depends on inclusion conditions and wallet settings. Make sure you can afford the displayed cap, but do not subtract it from the required USDC amount.

The transaction may remain pending and miss the displayed order deadline. Choose a wallet fee setting appropriate to current Ethereum conditions and monitor the public transaction hash.

Nothing yet. A usable Sell payment must have a final public Ethereum transaction hash. Check whether the wallet only queued or signed the request, and do not substitute an internal activity ID.

Not necessarily. Wallet history can include drafts, failed broadcasts, or activity on another network. Verify the network, final hash, sender, recipient, token contract, and amount on Ethereum.

No. Direct Sell funding must be exactly one native Ethereum USDC transfer from the recorded wallet to the dedicated address. Do not use a transaction that batches or combines other transfers.

No if the resulting transaction batches actions, uses a relay, or changes the on-chain sender. Create one standalone native Ethereum USDC transfer from the exact recorded wallet instead.

No. Each derived account has its own Ethereum address even inside the same wallet app. The direct transfer must originate from the exact address recorded for that order.

Availability depends on the supported order and bank details shown by the form. Enter both countries truthfully and do not select a different residence merely to make a payout account appear eligible.

Use each value only in the field labeled for it. An IBAN and a local account number can represent related details but are not interchangeable; ask your bank if you cannot identify the required value.

Choose the actual type assigned by your receiving bank, not the type you think processes faster. An incorrect type can cause rejection or return, so confirm it with the bank before funding the Sell.

Use the currently valid receiving details confirmed by your bank. Do not rely on an old statement or earlier order; if the change is still in transition, ask the bank which details accept incoming payments now.

Only if it is an eligible receiving account in your own name and the form accepts its actual country and details. Confirm that the provider can receive the quoted currency and does not redirect through an unrelated beneficiary.

Use it only if it provides supported receiving details in your own name for the quoted currency. Pooled accounts, missing beneficiary attribution, or transfer restrictions can prevent a reliable payout.

Do not assume a card number is a bank receiving account. Use only supported bank details issued in your name and confirm with the provider that they accept incoming transfers of the quoted currency.

No unless your bank confirms it can currently receive and credit the exact transfer. Reactivate or resolve restrictions before funding the Sell, because sending USDC does not remove bank-side limitations.

No. Complete each labeled field with the requested value and do not insert an address into a name, account, or routing field. If a required detail seems missing, contact Support before funding.

Enter the legal beneficiary name as held by the receiving bank, including a genuine suffix where the form permits. Do not add or remove name elements merely to shorten the entry.

Use the beneficiary name the bank confirms for that receiving account while keeping your legal customer information accurate. If the records differ materially, contact Support before sending USDC.

Answer the bank truthfully and provide the order or payout record it requests. Do not select a false purpose to accelerate crediting; contact Support if the bank needs information about the sending payment.

Use the payout confirmation and information legitimately shown for your order. If the bank needs data not provided there, open a Support ticket rather than guessing or copying details from another customer’s transfer.

No. A bank review of one payout is not resolved by another Sell. Respond accurately to the bank, keep the current order record, and contact Support if it requests sender or payment information.

Use the authenticated current order page instead. Notifications can be truncated, stale, or imitated; compare the complete dedicated address immediately before approving the one direct transfer.

Stop and identify what each request does. A normal direct transfer should not require an unexplained approval plus transfer, batch, or duplicate send. Reject unexpected prompts and start from the order instructions again.

No. Wallet labels can come from local contacts or third-party data and are not authoritative. Verify the complete address against the current order; if it differs, do not send.

Only send funds that are confirmed, spendable, and available at the recorded address. A pending incoming transfer may fail, be replaced, or remain unspendable, so do not create a Sell that depends on it until settled.