User stories generally don't include implementation details. They aim to capture the functionality the user is looking for:
As a customer, I want to be able to view the catalog of items for sale
As a customer, I want to be able to pay with a credit card
Note that these make no mention of databases, banks, APIs, connection details, or anything else. How you implement that functionality is up to you (the developer), as you could possibly store all your items for sale in text files, one file per item, and there is no database to speak of.
Now, of course, your PO can (and should!) put some additional details, requirements, acceptance criteria to give you a better idea of what they have in mind, and to keep the story from being too broad and vague.
As a customer, I want to be able to view the catalog of items for sale, including filtering by category. I want to be able to view thumbnail images of the items along with name and short description, in some kind of list.
As a customer, I want to be able to pay by credit card and save it for future order. I want to input my card number again if a new address is used, in order to combat fraud. I don't want to have to select which type of card is being used.
Whether you put the items into a
ListView or a
DataGridView or an HTML thing or some custom thing you wrote in Python, doesn't matter - as long as the functionality is provided.
How you store the credit card info, the customer doesn't care (local privacy laws notwithstanding, of course). They just want to be able to pay with a credit card, and not have click a radio button indicating whether it's a Visa, MC, AmEx, Discover, etc.
Note that implementing these stories may very well depend on those secondary actors you mentioned (database, bank). If you do indeed store your catalog in a database, then you (as the developer, not the customer) will need some way to retrieve information about those items. Or you'll need a way to interface with a credit card processing company to process card payments. If you don't already have those set up, they may simply be a task in one of these stories. Or they may become additional user stories or spikes:
As a developer, I need a way to interface with the CC processing company, so we can submit payments. Outcome should be a prototype program which can send request for payment and receive response.
I said stories generally don't include implementation details, but there are of course exceptions, with this being one (although it still makes no mention of actual implementation). Invariably, you will need to define stories to set up your environment, research various bits, etc, and those will be more technical / specific and contain implementations.