Payment Setup Fees: What Deliverables Should Be Written Down?

Stripe’s US standard-pricing page states that it does not charge setup fees. Adyen’s public pricing FAQ also says it has no setup or integration fee, while noting that a minimum invoice can apply depending on the industry or business model. Checkout.com advertises no setup fee within its tailored pricing offer. These are the providers’ own public statements, with their own product and commercial scope. [1][2][3]

They do not price every developer, broker or specialist project that might sit alongside the processing relationship. If an intermediary charges for work associated with a provider whose direct tariff has no setup fee, ask it to identify its separate service. Who receives the money? What would you receive from that party if you applied directly instead? Which part of its work is optional?

Equally, a paid project should not be dismissed solely because another provider advertises free setup. Compare the same deliverable, eligibility and operating requirements. A custom integration, migration or defined implementation service can involve work. Its price still needs a clear scope, rather than borrowing credibility from the processor’s name.

A test account demonstrates that software can be explored or integrated. It does not establish that the business has passed underwriting or can collect real payments. Checkout.com’s onboarding overview distinguishes a free test account from the application and decision needed before going live. [4]

Its integration guidance separately describes scoping, building, sandbox testing, production testing and launch after application approval. That gives a useful way to question a quote: which of those outcomes is actually included, and which depends on someone outside the supplier’s control? [5]

For example, a developer may be able to deliver a tested checkout against sandbox credentials while live credentials remain unavailable. That may fulfil a narrowly defined development commission. It would not demonstrate completion of a promise to deliver a live payment service. Write down which outcome you are purchasing before deciding whether the same invoice is acceptable.

Use the schedule below as a starting point for the commercial discussion. The rows are suggested work packages, not a claim that every processor sells these services or accepts milestone billing. Keep only the rows relevant to your project and replace broad phrases such as full setup with observable outputs.

Name the person who can accept each deliverable for your business. Give that person enough time and access to check it. A screenshot of an approval message, a successful payment animation or a folder of documents can look convincing without proving the underlying result. Ask for the application reference, provider account, test results or transaction record that supports the stated outcome.

Also record exclusions. If recurring billing, a second currency, another domain, reconciliation reports or post-launch fixes cost extra, make that visible in the first quote. Otherwise the cheapest apparent project can become a sequence of small additional commissions.

Ask what happens if the acquirer declines the business after document preparation, requests further evidence, changes its proposed terms or does not decide by the planned launch date. Those are different situations. They may leave different amounts of useful work completed and different decisions for your business to make.

Request a written allocation of the fee between work already commissioned, work completed, work not started and any third-party charges. Ask how the supplier proposes to treat each amount if the project stops. A statement that the whole fee is nonrefundable is a commercial term to understand; it does not explain the deliverables, and this guide cannot determine its enforceability or your legal entitlement.

A supplier may need an advance to reserve engineering time or begin an agreed review. If you accept that, specify the allocation of the advance, what makes it earned under the proposed agreement, the evidence you will receive and the process for disputed or incomplete work. Where terms are unclear or the exposure is material, obtain appropriate contract advice before paying.

Suppose the same proposed project is priced at USD2,400. Under one offer, the full amount is paid in advance and described as nonrefundable. Under an alternative you are considering, USD400 becomes due when a scoping report is accepted, USD800 when sandbox work is accepted and USD1,200 when the agreed production handover is accepted. Assume no tax, financing cost, cancellation charge or other fee, and assume later stages are not commissioned until their prerequisites are met. These are hypothetical terms for comparison, not a provider quote.

If the application is declined after the scoping report, the staged arrangement has paid USD400 and leaves USD2,000 uncommissioned. Under the advance offer, USD2,400 has already left your bank account; any amount returned depends on the actual agreement and circumstances. The difference of USD2,000 describes cash committed at that point, not a guaranteed refund or an expected loss.

If all stages are completed, both arrangements pay the same USD2,400. Staging changes when you commit money and which results you see first. A supplier might reject this structure or price it differently. The point is to make that trade-off explicit before comparing prices.

A technical scope should say which payment journeys will be tested and who supplies the accounts, credentials and business decisions. Include a successful payment, a decline, a refund, cancellation where relevant and reconciliation to the provider’s records. For a custom integration, agree how repeated or delayed notifications and uncertain responses will be handled. Keep the results tied to identifiable test cases.

Sandbox tests use simulated payments; production checks use the provider’s permitted live process. Agree the necessary approval and access before promising a live test date. Specify whether the handover includes only payment capture or also the reporting needed to trace deductions and payouts. First settlement may occur later than checkout activation, so decide whether reconciliation of that first payout is a handover condition or a separately supported follow-up.

Describe the response to defects: who investigates, what evidence they need, what period of correction is included and which changes count as new work. Avoid a completion test that depends entirely on the supplier declaring its own work finished.

List the domain, payment account, source code or configured plugin, provider dashboard, webhook configuration and operational instructions you expect to control or receive. Agree ownership, permitted use and continuing support in writing; do not assume the payment of a setup fee settles those questions. If the supplier stops working with you, who can operate the checkout and diagnose an incident?

Use provider-supported access roles and a secure handover process for credentials. A handover document can identify where keys are managed and who may rotate them without placing live secrets in a shared project report. Ask which access should be removed when the commission ends.

Outsourcing also needs a security-responsibility discussion. PCI SSC says that outsourcing payment processing does not remove the merchant’s responsibility to ensure payment account data is protected. Its guidance calls for clear shared responsibilities and confirmation of the merchant’s compliance obligations with the organisation managing the programme, such as the acquirer. Paying an implementation fee does not itself certify your checkout. [6]

Keep the signed scope, the version of the quote you accepted, payment evidence, completion records and the messages that change the work. When a new domain or payment method is added, record its price, dependencies and acceptance test before treating it as part of the original project. An informal request can otherwise become an argument about who delayed completion.

Use the same discipline when the merchant causes a delay. If you owe company documents, website terms or a technical decision, record an owner and a date. Ask whether the project clock pauses and whether rebooking carries a cost. Clear merchant responsibilities make the supplier’s promised work more assessable.

Before paying the final balance, reconcile what was commissioned with what was delivered and what remains open. If work is incomplete, identify the exact deliverable and the supporting evidence rather than assuming the whole project has no value. If processing is active, confirm which ongoing fees and support terms begin next.