Quick answer:

Before choosing a payment provider, check these 12 areas:

1. Your business needs and expected payment volume.
2. Payment methods actually available to your business.
3. The role of every company in the payment flow.
4. Merchant onboarding and approval requirements.
5. Integration, documentation and testing.
6. Security and customer-data handling.
7. Reliability and the complete payment journey.
8. Settlement and reconciliation.
9. Refunds, disputes and chargebacks.
10. Fraud and risk controls.
11. Support and escalation.
12. Total cost, contract terms and exit proces.

How to use this checklist:

Follow these steps before signing a contract:

1. Write down your business needs.
2. Send the same questions to every provider.
3. Ask for answers in writing.
4. Let your developer test the integration.
5. Let your finance team review the reports and settlement terms.
6. Score each provider using the scorecard near the end of this article.
7. Keep the final answers with your contract.

Do not treat a sales presentation as evidence. A good answer should be supported by a contract, product guide, technical document, sample report, live demonstration or written confirmation.

1. Write down your merchant requirements:

Start with your own needs. This stops you from paying for a service that does not fit your business.

Write down:

• Your business type and main products or services.
• Whether you sell through a website, mobile app, payment link, invoice or physical location.
• Your estimated number of payments each month.
• Your average and highest order values.
• Your expected monthly payment value.
• The cities or countries where your customers are located.
• Whether you accept one-time, repeat or subscription payments.
• Whether you need full or partial refunds.
• Which team will handle technical issues and payment questions.
• Which accounting or order-management system needs payment data.
• When you need to launch.

Also list any special needs. For example, a school may need one payment reference for every student. A marketplace may need to identify payments for many sellers. A travel business may need a clear refund process.

Decision question: Can the provider support the way your business actually sells and receives money?

2. Check the payment methods available to your business

A provider may show many bank, wallet, card or payment-network logos. This does not always mean that every payment method is available to every merchant.

Ask the provider for a written list that shows:

• The payment methods available to your business.
• The partner connected to each payment method.
• Whether the method is live, limited, planned or still waiting for approval.
• Any business-category restrictions.
• Any website or technical requirements.
• Any separate commercial approval.
• The currency supported by each method.
• The minimum and maximum transaction amount.
• Whether refunds are supported.
• Whether recurring payments or saved payment details are supported.

Also ask when the list was last reviewed. Payment availability can change.

Decision question: Will your customers receive the payment methods they need?

3. Understand every company and role

An online payment can involve several companies. A technology aggregator, bank, wallet, payment network and merchant bank may have different responsibilities.

Ask the provider to explain:

• Who provides the checkout, API or payment link.
• Who processes the payment.
• Who performs the regulated financial-service role.
• Who settles the payment to the merchant.
• Which bank account receives the settlement.
• Who handles refunds and disputes.
• Who receives a formal complaint.
• Who stores or can access customer payment data.
• Which company appears on the customer's payment screen or statement.

Ask for a simple payment-flow diagram. It should show the customer, merchant, technology provider, licensed partner and settlement account.

Do not accept a general answer such as "we are regulated" if several companies are involved. Ask for the name and role of the licensed institution that applies to your payment flow. Check important regulatory claims through an official regulator or partner source where possible.

Decision question: Do you know who is responsible at every stage of the payment?

4. Check merchant onboarding and approval

Ask for the complete onboarding list before signing a contract.

The list may include:

• Company-registration documents.
• Owner or director identification.
• Bank-account information.
• Tax information.
• Business address.
• Website or application review.
• Terms, privacy, refund and delivery pages.
• Product or service information.
• Risk review.
• Approval from the relevant payment partner.

Ask for the following in writing:

• One complete document list.
• The person or team responsible for onboarding.
• The normal review steps.
• Any separate partner approval.
• The reasons an application can be delayed or rejected.
• What happens if more information is needed.
• How the provider protects the documents you submit.
• How often business information must be updated.

Do not rely on a universal promise such as "go live in one day." The time can depend on the merchant, its documents, its website and partner approval.

Decision question: Can your business provide the required documents, website information and approvals?

5. Check integration, documentation and testing

A developer should understand the integration before the business sends live customer payments.

Ask for:

• A clear integration guide.
• Authentication instructions.
• A test or sandbox environment.
• Sample payment requests and responses.
• A list of payment statuses.
• Callback or webhook instructions.
• Webhook security and signature checks.
• Error codes and error messages.
• Retry and duplicate-payment handling.
• Refund instructions.
• Technical support contact.
• Supported programming languages, plugins or software platforms.
• API versioning and change-notice policy.
• Instructions for moving from test to live mode.
• A safe method for storing and changing secret keys.
• A status page or incident-notification method.

The developer should test successful, failed, pending, cancelled, timed-out, duplicate and refunded payments.

The developer should also test:

• A customer refreshing or closing the payment page.
• A callback arriving late or more than once.
• A payment being successful at the partner but not yet updated in the merchant system.
• A wrong amount or altered order reference.
• A network interruption during payment.
• A full and partial refund, if supported.
• Mobile screen sizes and slow mobile connections.

Before launch, ask the provider to confirm the final production settings and support contact in writing.

Decision question: Can your developer understand and test the complete payment journey?

6. Check security and customer-data handling

Security is a shared responsibility. Ask which security work belongs to the merchant, the technology provider and the licensed partner.

Ask:

• Does the merchant website or app ever receive card or wallet credentials?
• Is the payment page hosted by the provider or embedded in the merchant website?
• How are API keys and secret keys created, stored, changed and cancelled?
• How are callbacks or webhooks verified?
• Is payment data encrypted during transfer and storage?
• Which staff members can access merchant and transaction data?
• Are staff actions logged?
• How are security incidents reported to merchants?
• How long is data kept and how can a merchant request deletion where permitted?
• Which security standards or audits apply to the exact service?

Do not publish secret keys in website code, screenshots, email or public repositories. Give staff only the access they need. Enable multi-factor authentication when it is available.

Ask for evidence that applies to the service you will use. A general security logo is not enough.

Decision question: Are security responsibilities clear, and can the provider support its claims with current evidence?

7. Check reliability and the complete payment journey

Ask what happens before, during and after a payment.

Review:

• The payment statuses your system can receive.
• How long a payment may remain pending.
• How duplicate payments are prevented or identified.
• How the system handles retry attempts.
• How a merchant checks the final status directly.
• How planned maintenance is announced.
• How service incidents are reported.
• Whether a service-status page is available.
• Whether past uptime or incident information can be shared.
• How lost or delayed callbacks are recovered.

Do not rely only on a general uptime claim. Ask what the number covers, how it is measured and which services are excluded.

Decision question: Can your operations team continue working when a payment is delayed or a service is unavailable?

8. Check settlement and reconciliation

A successful checkout is only one part of the process. Your finance team must also understand what money was received and how it matches each order.

Ask the provider to show a sample report or export with:

• Merchant order reference.
• Provider or partner transaction reference.
• Payment status.
• Payment date and time.
• Gross amount.
• Fee or adjustment.
• Net amount.
• Refund information.
• Settlement date.
• Settlement or bank reference.
• Tax or withholding information, where applicable.
• Reason for any hold, reserve or adjustment.

Ask how often settlement happens and which licensed partner performs it. Ask about weekends, bank holidays, risk holds, reserves and other possible exceptions.

Do not accept "fast settlement" as a complete answer. Ask for the settlement terms that apply to your business.

Your finance team should test whether it can:

• Find one transaction by merchant order number.
• Match the gross amount, fees and net amount.
• Match the settlement report with the bank statement.
• Identify refunds, reversals and adjustments.
• Export the data in a useful format such as CSV or Excel.
• Give the records to an accountant or auditor.

Decision question: Can your finance team trace one customer order from payment to bank settlement?

9. Check refunds, disputes and chargebacks

Problems will happen in every payment system. The important question is how the provider handles them.

Ask:

• How do we request a full or partial refund?
• How long can a refund take?
• How do we see refund status?
• What happens when a payment remains pending?
• How do we investigate a failed payment?
• What information is needed for a dispute?
• Which company makes the final decision?
• Are there any refund or dispute fees?
• Is a partial refund available?
• Can a refund be cancelled after it is requested?
• Who communicates with the customer?
• What evidence and response time are required for a chargeback?
• How does a refund appear in reports and settlements?

Ask for written steps, not only a verbal promise.

Decision question: Does your team know what to do when a payment has a problem?

10. Check fraud and risk controls

Ask how the service helps merchants identify suspicious payments and protect customers.

Ask about:

• Transaction limits.
• Risk rules or alerts.
• Repeated failed attempts.
• Unusual amounts or transaction patterns.
• Access to blocked or reviewed transactions.
• Merchant actions required after an alert.
• Reserve, hold or delayed-settlement conditions.
• How a merchant can challenge a risk decision.
• Contact details for an urgent fraud concern.

The provider should explain what it monitors and what the merchant must monitor. No provider can promise that fraud will never happen.

Decision question: Does your team know how to identify, report and respond to a suspicious payment?

11. Check support and escalation

Ask for a support plan that includes:

• Support days and hours.
• Email, telephone and WhatsApp details.
• Expected response times.
• Urgent-incident process.
• Technical escalation contact.
• Settlement escalation contact.
• Required transaction information.
• Handoff to the licensed partner when needed.
• A ticket or case reference.
• Update frequency during a serious incident.
• The person who can escalate a delayed settlement.

Make sure your team knows which transaction reference to send when asking for help.

Test the support process before launch. Send one normal question and one technical question. Check whether the reply is clear and useful.

Decision question: Can you reach the right team with the right information?

12. Check total cost, contract terms and exit process

Do not compare only the headline transaction fee.

Ask about:

• Setup or integration fees.
• Transaction fees.
• Taxes.
• Refund fees.
• Dispute or chargeback fees.
• Settlement fees.
• Monthly or minimum charges.
• Reserve or security requirements.
• Currency-conversion costs.
• Plugin or custom-development costs.
• Contract notice period.
• Data-export and exit process.
• Fee changes and the notice period for a change.
• Contract length and automatic renewal.
• Service suspension and termination conditions.
• Liability limits and merchant responsibilities.
• Ownership of integration work and merchant data.

Ask for the complete commercial schedule in writing.

Calculate a simple monthly estimate using your expected number of payments, average order value, refunds and support needs. Compare the estimate with at least one high-volume and one low-volume month.

Decision question: Do you understand the total cost of using and operating the service?

Evidence to request before signing

Ask every provider for the same evidence pack:

• Written list of payment methods available to your business.
• Payment-flow and settlement-flow diagram.
• Complete merchant onboarding list.
• Draft contract and complete fee schedule.
• Integration guide and access to a test environment.
• List of payment statuses and error codes.
• Security responsibilities and relevant current evidence.
• Sample transaction, refund and settlement reports.
• Written refund, dispute and chargeback process.
• Support hours, response targets and escalation contacts.
• Data export and service exit process.

If a document is confidential, ask the provider to show it during a meeting or provide a suitable summary. Record what was checked, by whom and on which date.

Red flags to investigate

Pause and ask more questions if you see any of these signs:

• A logo is shown, but the provider cannot confirm the service available to your business.
• Important promises are verbal and are missing from the contract.
• The provider will not share a complete price schedule.
• The developer cannot see documentation or test the main payment cases.
• Settlement timing is described only as "fast" or "instant."
• Security claims are broad and do not apply to the exact service.
• Refund, dispute or chargeback steps are unclear.
• There is no named escalation path for a payment or settlement problem.
• The merchant cannot export its own transaction and settlement data.
• The contract makes it difficult to change provider or retrieve records.

A red flag does not always mean the provider is unsuitable. It means the merchant needs a clear written answer before continuing.

Simple merchant scorecard

Give each of the 12 checklist areas a score:

• 2 points: Clear written answer, suitable service and useful evidence.
• 1 point: Partly clear, or an important item still needs confirmation.
• 0 points: Not available, not suitable or no reliable answer.

The maximum score is 24.

• 20 to 24: Strong fit. Complete legal, technical and finance review before signing.
• 14 to 19: Possible fit. Resolve every one-point and zero-point item first.
• 0 to 13: High risk of a poor fit. Compare another provider or redesign the requirement.

Do not use the total score alone. A zero in a critical area such as legal role, security, settlement or data access should stop the decision until it is resolved.

Questions to send to any payment provider.

Copy and send these questions:

1. Which payment methods are available to our business today?
2. Which partner provides each payment method, and which services need separate approval?
3. Which licensed institution performs the processing, acquiring, wallet or settlement role in our payment flow?
4. Can you provide a simple payment-flow and settlement-flow diagram?
5. What documents, website pages and approvals do we need?
6. Can our developer review the integration guide and use the test environment before signing?
7. Which payment statuses, callbacks, retries and error cases must we support?
8. What security work belongs to us, to you and to the licensed partner?
9. Can you provide sample transaction, refund and settlement reports?
10. What settlement timing and exceptions apply to our business?
11. How do pending payments, refunds, disputes and chargebacks work?
12. What fraud controls, limits, holds or reserve conditions may apply?
13. What are your support hours, response targets and escalation steps?
14. What are all setup, transaction, tax, refund, dispute, settlement and monthly costs?
15. How can fees or contract terms change?
16. How do we export our data and leave or change provider?

How 1Pay.pk fits this checklist

1Pay.pk is a payment aggregation and technology platform for Pakistani businesses. 1Pay.pk is a brand of Setlexor Services (Private) Limited.

1Pay.pk is an official payment aggregator working with:

• 1LINK.
• easypaisa.
• JazzCash.
• Meezan Bank.
• JS Bank.
• Bank Alfalah.
• Bank of Punjab.

1Pay.pk provides the merchant-facing technology and coordination used to connect approved businesses to available partner payment channels.

Important licence information: 1Pay.pk provides payment aggregation and technology services. 1Pay.pk is not a bank, electronic money institution, wallet operator, PSO, PSP or independently licensed financial institution. Regulated payment processing, acquiring, wallet and settlement services are provided by the relevant licensed partners under the applicable merchant and partner arrangements.

Payment methods, onboarding, pricing, settlement and service availability depend on the merchant and the relevant partner's approval.

Merchants should ask the 1Pay.pk team for the payment methods, partner roles, commercial terms, technical requirements and approval process that apply to their own business.