Frequently asked questions
Clear answers, without the runaround
Filter twenty-five practical answers across accounts, transactions, integrations, technical issues, and support.
25 questions
Use the newest verification message sent to the email address entered during registration. Check the sender and destination before opening it. If it is delayed, review spam and filtering before requesting another message.
Confirm profile and business details, notification destinations, recovery methods, available security settings, and the location of transaction, payout, integration, and help areas.
The field may require confirmation, belong to shared business information, or be restricted by your role. Review nearby guidance and ask an account administrator before treating it as a technical problem.
No. Do not send passwords, one-time codes, recovery codes, API secrets, CVVs, or full card and bank account numbers.
Sign it out when that control is available, change your password from a trusted device, review contact and recovery details, inspect recent activity, and contact support with safe timestamps.
Be cautious of urgency, unusual sender addresses, unexpected links, requests for credentials, and unfamiliar destinations. Open the official site independently and verify through a known contact channel.
The payment outcome is not final. Check its created time, latest event, and payment-method context. Avoid repeating the same payment while the first attempt remains unresolved.
Confirm the final status, verify only non-sensitive input, allow the customer to contact their issuer, and offer another valid method only if the customer chooses. Do not promise that a retry will succeed.
Use a transaction ID first. Otherwise combine a narrow date range, amount, status, and internal order reference. Never search by or record full card data.
Two attempts can look similar but have different IDs and lifecycle events. Compare timestamps, statuses, and related adjustments before taking any cancellation or refund action.
A refund usually follows a completed payment through a separate adjustment. A reversal releases or undoes an earlier authorization or movement. Exact terminology and availability depend on the transaction state.
An eligible cancellation or void is generally available only before normal completion and only when the transaction and your permissions allow it. Check the event history first.
There is no universal period. Display timing can depend on the payment method, financial institution, processing route, weekends, and banking days. Track the refund reference and current status.
Pending funds may still depend on transaction or account conditions. Available balance is closer to payout eligibility, but a created payout is a separate record with its own ID and status.
Banking calendars, destination processing, account notices, review requirements, returned movement, or recorded adjustments can affect timing. Confirm that a payout record actually exists.
Review the transaction, adjustment, and payout details available in your account. Fee types and amounts depend on the account arrangement, so this Help Center does not state a tariff.
Keep it in a trusted server-side environment variable or managed secret store. Never embed it in browser code, mobile apps, repositories, screenshots, or support requests.
Correct validation errors rather than retrying them. For retryable failures, use bounded exponential backoff and the documented idempotency mechanism for write operations.
Delivery systems can retry after timeouts or non-success responses. Deduplicate by event or delivery ID and make the handler safe to execute more than once.
Capture the environment, UTC time, safe URL path, method, HTTP status, request ID, response duration, and a redacted response. Never include an authorization header or secret.
No. Test a refresh, private window, and likely extension conflict first. Clearing broad storage can remove sessions and locally prepared support requests, so export useful local records beforehand.
The site is designed for current desktop and mobile browsers, supports keyboard navigation, and adapts to small screens. Browser storage behavior may differ in private or restricted modes.
No. It validates and saves a prepared request on this device. Use the email button to open a message addressed to the support team, then send it from your email application.
Enter the reference number and matching email on the Request Status page. It can find prepared requests stored in the current browser. A locally created request begins with the status Prepared.
Attach only focused, redacted evidence. Remove passwords, codes, API secrets, full card and bank details, and unrelated personal data. The site records attachment information but does not store the file.
People sometimes use the phrase merchant mx while looking for practical payment-workspace guidance. This independent welcometothemx resource focuses on clear support information without claiming affiliation with a third-party brand.
A merchant mx search can cover many workflows; use the steps on this page and verify actions against the settings available in your own account.
