Two product capabilities
Account information and payment initiation solve different problems. One gives authorised access to specified account information; the other initiates a payment with the user’s permission through an account-servicing provider. A product may offer both, but its interface should make the distinction understandable to the customer.
Scope the permission
Ask what action the user is approving, which account is involved and what information the application needs. Access to transaction history should not be treated as blanket authority to send money. Equally, permission for a payment does not automatically describe every future data-access arrangement.
A budgeting example
A customer connects an account so a budgeting tool can categorise spending. Later, the tool offers to pay a bill. That new capability requires its own supported payment journey; the existing account connection is not, on its own, evidence that the bill payment was authorised.
Design clear records
Store the relevant permission reference, scope and action alongside each request. Let support distinguish an account refresh failure from an initiation failure. Product language should describe the actual capability, rather than presenting a single vague “bank connected” badge as proof that every banking feature is available.