TL;DR
You perceive this as a scope problem, but in all likelihood the underlying problems have more to do with how you visualize the work, how you collaborate with your development team, and how effectively you set the expectations of your stakeholders.
You should adopt an incremental, iterative approach that allows you to deliver features in almost any order. I provide some examples below of how this might work in your particular situation.
Prioritization, Vertical Slices, and INVEST Critera
As a Product Owner, you have the power to prioritize features in the Product Backlog to meet business requirements. If the customer wants to prioritize payments, then the right thing to do in an agile framework is to work with your development team to create a vertical slice of functionality for that work, and to make that the top priority.
As an example, you could use the INVEST mnemonic to create a theme around payment processing. The user stories in the theme would all center around payments, and the team would then wire up just enough features to deliver the business goal of accepting payments. The application might not even do anything else, but it would have a potentially-shippable payment feature that could be integrated into future product enhancements, or refactored and refined as the product evolves.
You might have some backlog items like:
As a user,
I want to be able to check out a shopping cart
so I can process my order.
As a user,
I want to fill in the credit card fields on the order form
so I can pay by credit card instead of with cash.
As a credit card processor,
I want the payor's billing address
so I can process the payment using address verification.
As an payment processor,
I want an order number to associate with a credit card charge
so that the order and the payment can be reconciled.
These stories form a theme. Anything that isn't truly essential for the theme can be stubbed out or left for future phases. As just one example, you might be tempted to flesh out the shopping cart beyond what's strictly necessary for this vertical slice. Pragmatically, all you really need for this set of stories to meet a reasonable Definition of Done and be demonstrable to stakeholders is:
- a "Check Out" button that provides an order number to the payment processing backend; and
- a payment processing backend that can be validated against the payment gateway's API (preferably in some sort of test mode).
Approaching the problem in this way allows you to meet the customer's needs and priorities without going overboard. Don't fall prey to the mentality that you need to build an entire hotel so you have somewhere to put an ice machine, when the core requirement simply says "I want a cold soda."
Create Minimalist Features
Features should be small, testable, and relatively independent of one another. As a Product Owner, you work with the stakeholders to identify the business priorities, and with the development team to identify "the simplest thing that could possibly work." A good development team will collaborate with you to identify minimalist core features, and help you pare away non-essential implementation details that allow you to build the product incrementally and iteratively.
Agile frameworks embrace change by accepting a priori that a certain amount of scope change, rework, integration-related refactoring, and other additional effort will be required over time as the product evolves. This is accepted in exchange for the ability to deliver vertical slices of functionality in almost any order to meet today's business goals, while retaining the ability to adapt to changing goals and requirements in the future.
Embrace Emergent Design
Customers have a need. You provide the vision by focusing on what, not how. Then collaborate with your team in a way that doesn't over-constrain the solution space. Give them goals and boundaries, and then turn them loose so that they can apply their subject matter expertise to the problem at hand, often in ways you might not even be able to imagine at the start of a project.