Your question is a business one, not a database one. The 'unique identifier', or your key, should be the key that the business uses to distinguish customers. Some may use a user-name, others may use Email, some may use SSN, some may use retina scan.
The database schema is a MODEL of the business reality, therefore, it should follow the keys that are used in the real world.
It won't help you much to assign a surrogate key, like IDENTITY or GUID, as you still won't be able to distinguish one customer from another, as you can't extract that property from the customer itself, and name is typically not enough. What would you do if a customer walks into the office and there are 4 other customers with the same name?
Let's say you have 2 customers named John Doe. You insert them into
the table and assign them surrogate primary keys with ID 34 for one,
and 237 the other. A customer walks into the store. Says 'hi, I'm John
Doe and I'm here to buy an item'. You type 'John Doe', and into the
screen to pull up his account, and you see 2 options - John Doe 34,
and John Doe 237. You look at the customer and ask "Are you John Doe
34 or 237?". The customer thinks you're crazy and walks away... The ID
doesn't identify the ENTITY, it is a relic of thought from 50 years
ago when magnetic tapes had address pointers...
The question mentions that the data collected is "customer's first and last names, address, date of birth, current mobile number".
If that is all you have to distinguish customers in the 'real world', that is your key.
Perhaps it is just first and last name, perhaps first and last name + address, perhaps just mobile number...
As for payment, again, the question does not provide enough information for you to give an answer. What payment methods are available? Cash? Checks? Credit Cards? Wire Transfers only? Can the customer pay in multiple payments and multiple payment methods?
Again - whatever the BUSINESS uses to distinguish payments, is what your key will be.