Narayan Bhat

This seems right, good work @lokesh185, you will have to fix few of the spellings though!

Hi @shubhanshu-mani. Thanks for showing interest. To clarify your doubts - Yes `payments_session` is an api endpoint currently. It can be followed from request till response from [here](https://github.com/juspay/hyperswitch/blob/8eac8cb3709ccab8819aa25c34b64b01a6d43750/crates/router/src/routes/app.rs#L90) - The...

Yes, this implementation may opt out of those trait functionalities. It can follow the same flow as `payment_methods_list`. This should be a stateless api, which can only read the trackers...

Hi @jeevaprakashdr. To provide more context on where this would be helpful, have a look at this function https://github.com/juspay/hyperswitch/blob/01f86c499d55f46b339ce6efa9bd2fd135de7a7d/crates/router/src/connector/stripe/transformers.rs#L362 This validates the `shipping_address` to check whether all necessary fields are...

That's great. Please mention the PR number here, once created

The json posted is not formatted, use json code blocks

Let me know your thoughts on this change @bernard-eugine.

One doubt that is bugging me is, the shipping address will be available with the merchant and should be sent by merchant during creating the payment, and billing address or...

Closing this issue as these changes are included the `billing_address` refactoring.

> @Narayanbhat166 , For the address validation errors, I feel that if the address fields fail multiple constraints, we should return all the errors, or atleast return that what are...