User stories are for documenting what value should be added to the product, and why. Implementation details (e.g. how the value should be added, tested, measured, or validated) are constrained by the story, but are not contained within them. They are deliberately left as separate artifacts to maintain flexibility and agility within the framework.
The specifications and implementation details are most often captured in other artifacts such as Acceptance-Test Driven Development (ATDD), Test-Driven Development (TDD), and Behavior-Driven Development (BDD) scripts and scenarios. These particular artifacts aren't mandated by the Scrum framework, but they will certainly give you a good starting point if you don't already have other effective process controls in place.
User Stories Are Not Specifications
The original poster (OP) asked the following question:
[A] customer wants a different processing for different credit cards, there are strict requirements that must be implemented and known so that test cases can be written... WHERE SHOULD I PUT IT IF NOT IN THE STORY?
A user story is a feature that delivers value, provides some context to guide conversations about implementation, and a point of view tied to a value consumer who will benefit from the value delivered by the feature.
The whole point of a user story is that the implementation details are not prescriptive. The team is free to implement the feature in any way that delivers the identified value to the value consumer within the appropriate context.
A Worked Example
A Sample User Story
This is easier to explain if you start with a less ambiguous set of user stories. Since the OP didn't provide an actionable user story that follows the INVEST mnemonic, I'll invent one for the sake of an example. Consider the following story:
As a user who prefers to pay by Discover card,
I would like the option to make my purchases with the Discover card
so that I am not limited to Visa, Mastercard, or American Express.
This provides a concrete feature, provides some context that can guide the implementation decisions the team must make, and identifies the value consumer as a Discover-card owning customer. That's not a set of specifications, but it's what you need to have the right conversations with the customer and with the team about how best to implement the story during an iteration of development.
Analysis and Implementation
The actual implementation is up to the team. The team will have to do some analysis to determine:
- The easiest way to implement a new feature.
- Which of the various implementation options will be easiest to support going forward, without accruing technical debt.
- How to apply the open-closed and YAGNI principles to ensure that your new feature is robust without being over-engineered.
One of the core principles of the Agile Manifesto is customer collaboration. A cross-functional, self-organizing team is expected to be able to collaborate with the customer to work out the implementation details within the guidelines provided by the user story.
If your user stories are not written well, or if the team doesn't have the skills or process maturity to do the just-enough analysis required by their agile framework, then this will obviously be much harder than it needs to be. Whole books have been written on the subject of how to create good user stories at the properly level of granularity; there is unfortunately no silver bullet, but it is a learnable skill for agile teams.
Test-Driven and Behavior-Driven Design
The best way to ensure that the analysis is sound, and that the implementation is both sane and supportable is through the use of TDD and BDD practices. For example, given the story above, the team should capture the planned implementation through artifacts such as:
Cucumber features with testable scenarios.
This is most useful for driving the development of acceptance tests, and for documenting user expectations of application behavior. For example, the user story should have one or more related Cucumber features that describes how the user is able to check out with a Discover card, and what that process looks like to the user.
RSpec tests that validate the behavior (not the internal implementation details) of new code features.
This is most useful for documenting and validating the intended behavior of the feature within the application. For example, the user story will drive the creation of unit and integration tests that ensure that using a Discover card invokes whatever card-specific behavior the application requires to authorize a sale through the payment gateway.
The specific tools don't matter. If you don't like Cucumber or RSpec, use whatever tools or methodologies work best for your team. However, the point is that the implementation details are based on the user story, but aren't prescribed by it. Instead, the implementation (or specifications, if you prefer) are details to be worked out during the development of the feature in a collaborative fashion.