-
Notifications
You must be signed in to change notification settings - Fork 4.2k
feat(connector): [chargebee] consumes required fields to support transaction monitoring #7774
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Changed Files
|
crates/hyperswitch_connectors/src/connectors/chargebee/transformers.rs
Outdated
Show resolved
Hide resolved
crates/hyperswitch_connectors/src/connectors/chargebee/transformers.rs
Outdated
Show resolved
Hide resolved
crates/hyperswitch_connectors/src/connectors/chargebee/transformers.rs
Outdated
Show resolved
Hide resolved
|
||
/// Number of attempts made for invoice | ||
#[schema(value_type = Option<u16>, example = 1)] | ||
pub retry_count: Option<u16>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need this information here , we already might have this is in intent right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to update the payment_intent's feature metadata with correct retry count(coming from the webhook or other means from billing processor instead of defaulting it to 1 for first webhook we receive). Since payment intent feature metadata is getting updated in the record payment attempt we need this in PaymentAttemptRecordRequest.
@@ -554,6 +554,8 @@ impl RevenueRecoveryAttempt { | |||
transaction_created_at: self.0.transaction_created_at, | |||
processor_payment_method_token: self.0.processor_payment_method_token.clone(), | |||
connector_customer_id: self.0.connector_customer_id.clone(), | |||
retry_count: self.0.retry_count, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we not use self.0 here its not very readable
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok
048295f
…acilitapay-pix-pmt * 'main' of github.com:juspay/hyperswitch: (21 commits) refactor(required_fields): move pm required fields to pm crate (#7539) fix(connector): [noon] address `next_action_url` being `null` for cards in 3ds payment (#7832) refactor(middleware): add middleware to record metrics for request count and duration (#7803) chore(version): 2025.04.18.0 chore(postman): update Postman collection files fix(connector): [globalpay] handle edge case where currency comes as empty upon payment decline (#7812) refactor(cypress-v2): change `Authorization` and `payment_methods_enabled` for v2 cypress tests (#7805) fix(connector): [Cybersource] send type selection indicator for co-batch cards (#7828) feat(payment_method): add logic for setup_future_usage downgrade and add filter based on zero mandate config (#7775) refactor(accounts): move dashboard_metadata table to accounts_schema and point v2 to v1 dashboard_metadata (#7793) chore(analytics): opensearch client creation based on config (#7810) ci(postman): update assertion error message for nmi collection (#7765) feat: add primary key not null query to generic filter function (#7785) chore(version): 2025.04.17.0 chore: change payment method files ownership to `hyperswitch-payment-methods` (#7808) feat(vsaas): modify api key auth to support vsaas cases (#7593) ci(cypress): verify mandate id to be `null` if payment id not `succeeded` (#7749) feat(connector): [chargebee] consumes required fields to support transaction monitoring (#7774) ci(configs): remove vault private key from configs (#7825) chore(version): 2025.04.16.0 ...
Type of Change
Description
To support the transaction monitoring feature for charge bee we need to consume the following fields :
Billing Address details for invoices such as city, state, country, zip and invoices next billing time and retry count.
Since all these details are in invoice level we should be storing them in payment intent. Billing address will be stored in billing_address column of the payment intent table and for adds a new column in feature metadata of the payment intent and the retry_count logic will be like the following:
Why do we need to consume retry count?
If a merchant onboards and merchant has previous subscription there is a chance that we will miss those webhooks before
before registering our webhook endpoint in the billing connector. Since retry count will not be synched in our system and billing connectors. To avoid this we will be consuming retry count and use the count as the retry count for the payment intent. For further webhooks we increment the count by 1.
In chargebee we wont receive retry count directly. So we will consume the listed payments and its length will be equal to retry count.
Additional Changes
Motivation and Context
How did you test it?
the feature metadata should look like this in payment intent
and the payment intent table should have billing address in it in an encrypted form
Checklist
cargo +nightly fmt --all
cargo clippy