also suggest and guide me where i can do , or need to deploy my own content on internet and on that i have to test

i'll give a few hints though that is probably not what you are after.

testing. owasp zap is unrelated with the rest.other techs are merely third party payment systems that allow you to create test accounts and play with the api without actually performing any transaction.

traffic monitoring

you do not need complex forensic tools with IA. such platforms merely require a handful of known traffic and the rest should simply be blocked entirely. no need for much complex analysis : anything unexpected is a red alert.

SIEM stuff are typically overkill expensive and inefficient in such contexts.

the reports are pretty much templated in the docs of each of the regulation/ruleset/checklist you mention.

GDPR has little to do with the rest which focuses on security. the focus of the GDPR itself if unclear to many of us but likewise the reports are templated and nobody checks anything anyway.

email security

spf, dmarc and dkim are essentially about email deliverability.

dkim allows to sign emails if you configure it to do so which does have some security implications.

RBAC should be global and does not really fit in the email section.

likewise MFA and comprehensive understanding and crafting of auth schemes are probably more important for user accounts than email. such platforms do not necessarily even receive email directly.

WAF

ssl3 is only safe until yet another catastrophic breach is found.

beyond that, you need to reflect on what you are securing.

auth should not be protected by ssl only but requires challenge response mechanisms.

likewise stealing credentials and replay attacks are quite an issue.

these need to be dealt with at the code level. not in a waf.

the rest of the waf job is to protect random platforms from a bunch of known attacks. that is plain useless when you know the format of the urls you use and make sure to filter them adequately in some reverse proxy.

you are totally ignoring system security, security of the architecture, dos protection, enforcing rbac at different levels including system and network, … there is much more to securing a platform than some generic checklist.

The below may not be answering to your ASK though can be useful insight as you think thru for the project. 

If security guidance is the outcome of the project, you should at least know what good looks like for a secure Web environment. 

In fact, there is no foolproof web based security control. The web environment (as example) is always coupled with known vulnerability coming from insecure codes and unpatched software used, not forgetting there are poor security baseline (not using mfa, expose DB to Internet, etc) and overly complex design (multiple COTS, APIs, SaaS, etc) … all these leads to poor insecure architecure.

Hence, i feel that you should ankle on the minimal viable security architecture to start off with. And most of the time, it is to coduct threat modeling even before you identify the right mitigation and perform the penetration testing. I also caution that you not follow high level 'security hype' like defence in depth and enforce zero trust when you are not clear of the threat scenario to mitigate.

Those scenarios can include insider abuses, unauthorise access using stolen credentials, destroy of backup due to ransomware, planted webshell through low hanging vulnerability (from owasp), rce exploits, ddos (l3,l4,l7) and list goes on.

Perhaps a lab environment with web, app and db can be the kick-start of your journey and those mentioned in your ASK can then add context. Search for the Zero Architecture under NIST NCCoE on such lab setup if that interest you on the above. There is also security antipattern sharing by NCSC worth checking out.

at the architecture / conception level, a few things to consider for ecommerce.

write only sql access. no delete, no changes allowed. keep histo and limit the volume of changes.

web uis privsep. the level of access of admin and user accounts are different. this often calls for separate frontends with separate db privileges. some situations may call for a limited api rather than sql for the hosts that deal with unprivileged clients.

containerization

avoiding useless credentials. i had rather connect to a resource without password and drop privileges after the connection is made than having some piece of code that knows the password.

user auth db and other cryptographic operations separation. possibly dealing with other tokens such as sessions and anti replay stuff. the main issue would rise when you use event driver soft that process multiple queries in the same memory segment in parallel. stealing credentials is a real life risk while performing a sophisticated havk to dump someone else's basket contents is a non issue. a separate db can also help drastically with compliance with rgpd though ecommerce sites typically will not gain much there.

--

as far as the minimal architecture go, a single machine with a db and web server is quite viable.

you probably want to start with at least a reverse proxy layer. 

i do not consider the separate db layer as that mandatory but most people would not consider an arch that does not feature that.

typically reverse proxies speak with no one including their own siblings beyond their backends. connections are ingress on the wan side and egress on the back. web servers spek with their dbs and possible separate internal apis running on different servers. db backends replicate so they usually chat with their siblings.