How can we help?

Start with your legal business location, the products you sell, and the countries your customers are in. Payment-method eligibility is assessed for that combination; a logo in the directory is not an approval for every business.

Send your website, sales channel, expected monthly volume, and launch plan through the contact form. Describe subscriptions, preorders, digital delivery, or other special arrangements so the proposed setup reflects how you actually sell.

Prepare the company’s legal name and registration details, ownership information, a description of the goods or services, and settlement account information. Ask for the checklist that applies to your business and selected payment methods before collecting documents.

The company, website, and bank account details should be consistent. If another entity fulfills orders or handles customer support, explain that relationship. Submit sensitive supporting documents through the agreed secure channel, rather than placing them in a public inquiry.

The review team needs to understand what customers can buy and how the purchase works. Prepare accessible product pages with prices, seller information, contact details, delivery conditions, and cancellation or refund policies. Include disclosures required in the markets you serve.

If the site is not public, describe its development stage and ask how review materials should be supplied. Provide a representative purchase flow. Do not assume that a blank landing page or approval for a different website also covers the store you intend to launch.

Contact the team before changing the contracting company, ownership, website, or main product category. Explain what is changing, the planned date, and whether existing orders, refunds, or settlements will be affected.

A new entity or different business activity may require another review or agreement. Keep the existing responsibilities clear until the change is accepted. Do not route a new business through an older approval simply because it uses the same brand name.

Ask the team for the verification process before changing settlement bank details. Prepare the account holder name, bank location, currency, and evidence requested for the approved account. Explain whether the contracting entity is also changing.

Confirm when the new details take effect and which account will receive a payout already in progress. Do not treat a change request as an immediate switch. Never send online-banking passwords or security codes to make the request.

Give each member of the team only the access required for their work. Separate order support from sensitive actions such as refunds, bank-detail changes, and access administration. Confirm the access controls available in your agreed setup.

Avoid sharing a personal login across staff. Keep an owner for access reviews, remove access when someone leaves, and document who can approve financial changes. If you suspect that access has been compromised, notify the team without including passwords in the message.

A payment mix can include international cards and local methods, but each option needs to be checked against your contracting business and target market. Share both where the company is based and where its customers live.

Compare customer currency, onboarding requirements, refund handling, and settlement conditions for each method. Begin with the choices relevant to your customers rather than enabling every logo. Confirm the approved methods before announcing them on your website.

They may be different. The currency displayed to the customer, the currency used for the payment, and the currency paid into your bank account depend on the method and commercial arrangement. Confirm all three before launch.

Ask where any conversion takes place, how its charges are calculated, and which currency applies to refunds. Do not assume that a method’s availability in a country means it supports every currency or every settlement account in that country.

An order placed with a delayed payment method is not necessarily paid. Keep it separate from confirmed orders and provide the applicable instructions and payment deadline. Decide how long inventory will be reserved while the customer completes the payment.

Before shipping, check the confirmed payment result through your integration or agreed transaction-checking process. When the deadline passes, check the actual transaction state before releasing stock or asking the customer to create another order.

An issued payment instruction is tied to its chosen payment route. For a store change, use the supported cancellation and new-order process rather than reusing the old payment number.

First confirm the original request is unpaid. Cancel or invalidate it as appropriate, issue the replacement, and tell the customer which instructions remain valid to avoid duplicate payments.

On a supported phone, wallet checkout may open the installed app. A desktop flow can instead show a login or QR handoff to the phone. The device and app state affect the screens displayed.

Let the customer complete the wallet step before checking the final payment result. Opening the app or scanning the code alone is not proof that the order has been paid.

The name on a statement can depend on the merchant information sent through the payment route and how the issuer displays it. It may differ from the website’s familiar trading name.

Match the date and amount to the order receipt. The merchant can check registered shop information; the cardholder should ask the issuer about the final statement display or an unrecognized charge.

Compare the instructed account and amount with the transfer receipt. In a per-order account arrangement, reusing an earlier account, combining orders, or deducting transfer fees can prevent automatic matching.

Keep the receipt and original order reference for investigation. Do not transfer the same amount again before the first payment is located. Bank execution dates can also differ from the date the customer submitted the transfer.

Share your platform, version, store URL, and any checkout customizations. Include subscriptions, multiple stores, and installed payment extensions. These details help identify a compatible connection rather than assuming every platform configuration behaves the same way.

Before installation or launch, confirm who configures the connection, how orders and refunds synchronize, and how changes will be tested. Keep a way to restore the earlier setup if the connection affects an existing store.

Use a payment link when an order starts through a conversation, invoice, email, or another direct-sales channel. Confirm the product, price, currency, and customer reference before creating or sharing the request. A link should identify the particular order being paid for.

If the agreed order changes, check whether the existing request needs to be replaced. Track the confirmed payment against that order before fulfillment. Avoid leaving several inconsistent requests in the conversation without explaining which one the customer should use.

Test successful, failed, cancelled, and waiting payments; an interrupted return to the store; and refund handling. Include repeated clicks and duplicate notifications so the same payment cannot create multiple fulfillments. Use the test instructions approved for your connection.

Check what the customer sees and what your staff can verify. Confirm order references, currencies, paid status, stock handling, and support messages. Do not use live customer card information to improvise tests, or assume a successful test means business approval is complete.

An expired or invalidated request should not be treated as a new payment invitation. Check whether a payment was already completed, then create a replacement request through the supported process if the order is still valid.

Share the new link clearly and withdraw the old instruction. Expiry of an unpaid request does not cancel or refund a payment that had already completed.

A created order or an opened payment page does not prove that payment was completed. Pending means the customer still needs to finish paying; an expired or failed payment should not be shipped. A card authorization can also be separate from the final charge.

Before fulfillment, confirm the final paid status and amount in the payment record, then match its transaction reference to the store order. If the customer says they paid while the order is still waiting, check the payment notification and bank or wallet record before requesting another payment.

First confirm that the refund itself succeeded. Accepting a return or cancelling an order in the store is not the same as returning the payment. Check the refunded amount and refund reference for the original transaction.

When the customer receives the money depends on the payment method and its issuer or bank. A completed refund may appear in a later card statement or be offset against the original charge. Check the relevant statement period before submitting another refund.

• Card: the issuer’s statement and billing cycle determine when the credit becomes visible.
• Wallet: check the refund entry in the relevant wallet account.
• Bank-based refund: check the requested recipient account and bank processing date.

A merchant refund returns money through the supported refund process. A dispute is raised through an issuer or payment provider and has its own reason, evidence requirements, and response deadline. Handling the customer’s return request does not automatically close an open dispute.

Read the notice and preserve the order, product description, delivery evidence, and customer messages. Confirm how to respond through the applicable process, including whether a refund is appropriate while the dispute is open. Do not ignore the notice simply because the customer previously agreed to a return.

Check the error, refund amount, previous refunds, and method’s deadline. If refunds use an unsettled balance, insufficient available funds can prevent processing.

Resolve the cause, then check whether the failed request must be submitted again. Do not assume it will retry automatically or refund through another route before checking for duplicates.

Refund windows vary by method. Check the original payment completion date against the deadline applicable to that transaction; the return request date is not necessarily the starting point.

If the window has passed, do not keep submitting the same request. Arrange an appropriate alternative with the customer after confirming the original refund has not succeeded.

Do not overwrite a completed payment to represent a different amount. Return an overpayment through the supported refund process; collect an additional amount with a separate customer-approved payment.

Link the correction to the original order and retain both records. Editing an order’s displayed total does not itself move money or alter the original payment.

Partial refund support differs by payment method. Verify the refundable remainder, the selected items, and whether previous refunds have reduced the amount available.

For a method without partial refunds, do not disguise the operation as a full refund. Agree on a supported way to correct the order and keep the payment and return records consistent.

The card issuer determines how a refund to an expired, replaced, or closed card account is received. Ask the customer to contact the issuer with the refund reference.

Check the original refund result before arranging another payment to the customer. A changed card does not by itself prove that the refund failed.

Refer to the settlement schedule and transfer conditions agreed for your account. Confirm the sales period covered, processing cutoff, expected transfer date, minimum amount, currency, and bank details. These are different from the date a customer paid.

When checking a missing payout, distinguish the expected date, a transfer being initiated, and the bank receiving the funds. Holidays, transfer conditions, and an applicable review can affect the sequence. Ask about the specific settlement reference rather than treating every unpaid transaction as a late bank transfer.

“From” is a starting rate, not a universal quote. The applicable processing rate can depend on the method, market, business type, volume, and card category. Check whether a fixed transaction charge is added and which currency it uses.

Review the complete proposal, including any setup, recurring, conversion, settlement, refund, or dispute charges that apply. Ask for an example based on your usual order value. The agreed commercial terms take precedence over a simplified website rate.

Ask for the reason, affected amount and period, relevant agreement clause, information required from you, and the next review step. Keep the request tied to a settlement reference and preserve the written response. A request for documents and an indefinite unexplained delay are different situations.

Provide relevant order and fulfillment evidence through the agreed secure channel. If the explanation is unclear, escalate the matter and identify the entity responsible for settlement. Keep cash-flow planning separate from assumptions about release dates, and obtain professional advice where a contractual dispute requires it.

Keep secret credentials on the server or in an approved secrets manager, separate from application source and public client code. Use only the credentials and environment described in the documentation supplied for your approved connection.

Do not paste secrets into screenshots, inquiry forms, chat messages, or diagnostic logs. Limit access and document a replacement process if a credential is exposed. Public browser code and private server credentials serve different purposes and should not be interchangeable.

Use the verification procedure specified for your connection before acting on a notification. Match the event to the order and transaction, check its meaning, and make processing safe to repeat. A duplicate delivery should not cause another shipment or refund.

Keep a record of what was processed and how errors will be retried. If a notification arrives late or in an unexpected order, reconcile the current transaction state instead of assuming the latest message is the entire history. Agree on monitoring before launch.

A hosted page can change where payment data is collected, but your responsibilities depend on the implementation and applicable security requirements. Review the actual data flow and confirm the obligations for your setup with the responsible provider and qualified adviser where needed.

Protect your website, credentials, staff access, and order records. Do not collect full card numbers or security codes in ordinary support forms. Revisit the assessment if checkout scripts, plugins, or the method of collecting payment data changes.

Find the order and payment reference, then verify the current transaction state through the agreed process. Check the amount, currency, payment method, and whether there are multiple attempts. A delayed store update or interrupted return may need reconciliation rather than a second payment.

Do not ask the customer to pay again until the earlier attempt is checked. If you need help, provide the references, time, observed status, and relevant error information. Explain to the customer what you are verifying and avoid treating a screenshot as final confirmation.

Contact the shop where you placed the order for shipping, product changes, cancellation requests, or return conditions. The shop holds the order and fulfillment information. Keep its order confirmation and the reference shown on your payment receipt.

If the issue concerns the payment itself, ask the shop to check the matching transaction first. When contacting PayPort, include the shop name, order reference, payment date, amount, currency, and a clear description. Do not include full card details or security codes.

Include your business or shop name, order and transaction references, payment method, amount and currency, date with timezone, expected result, and what happened instead. For technical issues, add the environment, error message, and steps that reproduce the problem.

Remove passwords, API secrets, full card details, and unnecessary personal data from attachments. If evidence contains sensitive information, ask for the approved submission channel. Keeping one clear case reference makes follow-up easier than sending the same issue as several unrelated requests.

Authentication and payment completion are separate steps. Check whether an issuer challenge was completed or interrupted, and whether a payment already succeeded before asking the customer to retry.

For a challenge the customer cannot complete, the card issuer can clarify its authentication requirements. Never ask the customer to send an authentication password or one-time code to merchant support.

First distinguish an authorization from a completed charge. Compare the store’s successful transactions, amounts, and references with the customer’s statement; two displayed entries do not automatically establish two completed payments.

If two payments actually completed, investigate the duplicate and use the appropriate refund process. If one entry is a temporary authorization, the issuer can explain its release. Do not refund a transaction that never completed.

Use an up-to-date mainstream browser such as Chrome, Edge, Safari, or Firefox. Try opening the link in a full browser rather than an embedded app browser, and check whether extensions or network restrictions are blocking the page.

Before repeating a payment, verify that the previous attempt did not succeed. If the issue continues, record the browser, device, time, and error message so the affected step can be identified.