soroush.asadi
ec51e87d2d
A generic multi-client payment gateway so FlatRender, meezi.ir and bargevasat.ir can all pay through ZarinPal's single verified callback domain (pay.flatrender.ir). New Go service services/payment (clones the notification skeleton + vendored deps): - migration 31_payment_broker.sql — `payment` schema: client_apps, transactions, webhook_deliveries. - ZarinPal v4 client ported from the proven identity PaymentService (request.json -> StartPay -> verify.json; codes 100/101). - client API: POST /v1/pay/request + /v1/pay/inquiry, authed by X-Api-Key + HMAC body signature; GET /callback/zarinpal (the single verified endpoint) verifies, then 302s the user back to the site's return_url (signed) and fires a signed, retried webhook. - per-client ZarinPal merchant override (default = shared merchant); amount stored canonically in Rial, unit to ZarinPal env-configurable. - admin API /v1/admin/* (FlatRender admin JWT): client-app CRUD + key issue/rotate + transactions list. Deploy wiring: payment-svc in docker-compose.v2.yml (host port 1607), pay.flatrender.ir server block in mirror-nginx conf, ENV_FILE + README updates (cert SAN + manual migration note). Admin UI: src/components/admin/PaymentsAdmin.tsx (client apps with one-time key reveal + rotate, transactions table) + /admin/payments page + nav link + fa/en strings; pay-admin proxy route to payment-svc. Docs/SDK: deploy/PAYMENTS.md (integration contract) + deploy/sdk/flatpay.js (zero-dep Node client + webhook verifier) for meezi/any site. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3.6 KiB
How to Contribute
Your First Pull Request
We use GitHub for our codebase. You can start by reading How To Pull Request.
Without Semantic Versioning
We keep the stable code in branch main like golang.org/x. Development base on branch develop. We promise the Forward Compatibility by adding new package directory with suffix v2/v3 when code has break changes.
Branch Organization
We use git-flow as our branch organization, as known as FDD
Bugs
1. How to Find Known Issues
We are using Github Issues for our public bugs. We keep a close eye on this and try to make it clear when we have an internal fix in progress. Before filing a new task, try to make sure your problem doesn’t already exist.
2. Reporting New Issues
Providing a reduced test code is a recommended way for reporting issues. Then can be placed in:
- Just in issues
- Golang Playground
3. Security Bugs
Please do not report the safe disclosure of bugs to public issues. Contact us by Support Email
How to Get in Touch
Submit a Pull Request
Before you submit your Pull Request (PR) consider the following guidelines:
- Search GitHub for an open or closed PR that relates to your submission. You don't want to duplicate existing efforts.
- Be sure that an issue describes the problem you're fixing, or documents the design for the feature you'd like to add. Discussing the design upfront helps to ensure that we're ready to accept your work.
- Fork the bytedance/sonic repo.
- In your forked repository, make your changes in a new git branch:
git checkout -b bugfix/security_bug develop - Create your patch, including appropriate test cases.
- Follow our Style Guides.
- Commit your changes using a descriptive commit message that follows AngularJS Git Commit Message Conventions. Adherence to these conventions is necessary because release notes will be automatically generated from these messages.
- Push your branch to GitHub:
git push origin bugfix/security_bug - In GitHub, send a pull request to
sonic:main
Note: you must use one of optimize/feature/bugfix/doc/ci/test/refactor following a slash(/) as the branch prefix.
Your pr title and commit message should follow https://www.conventionalcommits.org/.
Contribution Prerequisites
- Our development environment keeps up with Go Official.
- You need fully checking with lint tools before submit your pull request. gofmt & golangci-lint
- You are familiar with Github
- Maybe you need familiar with Actions(our default workflow tool).
Code Style Guides
Good resources: