Short answer, you can probably use an After hook, more on this here, but it's not recomended for your case. BDD is used for communication with non-technical stakeholders
From how you've written the scenario outline, it seems that this only runs once and if the response if different form 200, then the last 2 steps will fail (or even the first Then).
If the only thing you need to check is the happy flow, in which the response is 200, there is no need for Scenario Outline with Examples. Simply create one scenario.
Background
Given I use the API header information
| Content-Type | application/json;v=3 |
And I connect to postgresql
Scenario: Happy flow
And I get the "Request" payload from "5NB_CARD-A_Request" file for the scenario "CardA_Scenario1"
And I store the input payload individual field details for database validation
And I form a client with this resource url "/transaction"
When I make a POST call and capture the response
And I get the "response" payload from "5NB_CARD-A_Response" file for the scenario "CardA_Scenario1"
Then I validate the output response with expected data
And I verify the HTTP error code is "200"
And I fetch and validate latest created data from "transaction" table
And I validate the created card is inserted into "field" table
If you are expecting to add more response codes then it might be a good idea to rewrite the scenario outline in a different way. There is no need for After keyword for your verification (Then steps). You are writing them only once anyway, when using scenario outline.
Background
Given I use the API header information
| Content-Type | application/json;v=3 |
And I connect to postgresql
Scenario Outline:
And I get the "Request" payload from "5NB_CARD-A_Request" file for the scenario "CardA_Scenario1"
And I store the input payload individual field details for database validation
And I form a client with this resource url "/transaction"
When I make a POST call and capture the response
And I get the "response" payload from "5NB_CARD-A_Response" file for the scenario "CardA_Scenario1"
Then I validate the output response with expected data
And I verify the HTTP error code is "<HTTPCode>"
And I fetch and validate latest created data from "transaction" table
And I validate the created card is inserted into "field" table
Examples:
| HTTPCode |
| 200 |
Keep in mind that you will need to manage the last steps differently if you are adding more response codes.
It also might be a good idea to hide details such as | Content-Type | application/json;v=3 | and manage them inside the step definition.
Update:
What I gathered from your comment is that you want to have those last 4 steps (Then steps) written only once inside a feature file and all the scenarios to use them.
As far as I know, there is no After which can execute the verification steps same as Background does for the preconditions, in the Gherkin language.
There is a way to simplify this, but it reduces reeadability. For example, if you have 10 scenarios and 2 scenario outlines that use the exact same four Then steps, then you could try nesting all of them in a more general one and if steps come from different step definistion files, then you could use picocontainer to group them and reduce the number how many times you call them inside the feature file. More details here .
Problem is that your Then steps are a bit complicated to be written in just one or even 2 simpler steps, because you have 3 params and 5 verifications.
To conclude, I think it's better to have them written for each scenario / scenario outline. I would be difficult for another person to look at the feature file and not see any Then, only to find them at the bottom. A better way would be to try and group more scenarios in scenario outlines, so the steps don't repeat that much.
Hope it helps!
