Is Acceptance Criteria Written for User Stories the list of Test Cases in Agile/Scrum methodology?

In Agile/Scrum methodology, the customer requirements are written as several user stories which are small enough to complete in a sprint. To claim a particular user story is completed, all the criteria listed in acceptance criteria must have been passed. Acceptance criteria may also be referred as verification criteria for the user story. The question that the developers have is; is it that the acceptance criteria all about writing down the test cases to test the user story? What should acceptance criteria focus on? Lets analyse this with an example user story. 

Example user story:

"As a bank account holder, I want to add my friend as payee, so that I can transfer money to him at any time online".

Acceptance Criteria for above story:(Not recommended way)

• Login into bank website and navigate to 'Add new payee' button and fill the payee details such as payee name and bank details.
• Click on 'Cancel' button to see if new payee addition is cancelled.
• Click on 'Confirm' button and see the addition of payee is successful
• Check that a new database entry in the 'payee' table has been added.
• Run the unit test automation scripts for adding new payee and verify the test reports.
• Check that the SMS is sent using SMS web service to the customer.
• Click on delete button to see if the new payee entry gets deleted.
• Once payee is deleted, click 'payee list' link and verify that newly added payee name does not appear.

Above acceptance criteria details out too much implementation specific details which is not really required to be written as acceptance criteria. The developer carries out many more tests during implementation such as unit testing, the developer tests other impacted/affected modules which need not go as acceptance criteria. Such criteria does not talk about the overall goal of the user story. They does not even make sense for our stake holders to go through. Some of above criteria can only be understood by the developers. 

Let's do another attempt to write acceptance criteria that all stake holders can understand and criteria focus on the goal of the user story.

Revised Acceptance Criteria:(Recommended way)

• Verify that there is an option which is clearly visible to the account holder to add new payee.
• Verify that the software has option to confirm or cancel the addition of new payee during the payee addition process.
• Verify that account holder can select the new payee added and there is an option displayed called 'transfer money'
• Verify that account holder can transfer the money to to newly added payee a limited amount for the first time.
• Verify that an SMS is delivered when a new payee is added to the account holder.

The bottom line is that it is essential to understand the difference between test cases and acceptance/verification criteria. The acceptance criteria should elicit the customer requirements than detailed test cases. Certainly the user story needs to be tested at minute level by the developers before the story is claimed to be done and also developer checks if everything defined in 'Definition of done' check-list is met or not. The definition of done can have things like testing non-functional requirements, code reviews, impacts tested etc.

Also it is to be noted that 'definition of done' is not to be confused with acceptance criteria. The definition of done relates to when can the software be shippable and may not apply for individual stories.