feat(connector): [chargebee] consumes required fields to support transaction monitoring#7774
Merged
Gnanasundari24 merged 10 commits intomainfrom Apr 16, 2025
Merged
feat(connector): [chargebee] consumes required fields to support transaction monitoring#7774Gnanasundari24 merged 10 commits intomainfrom
Gnanasundari24 merged 10 commits intomainfrom
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
srujanchikke
previously approved these changes
Apr 10, 2025
Aprabhat19
reviewed
Apr 10, 2025
|
|
||
| /// Number of attempts made for invoice | ||
| #[schema(value_type = Option<u16>, example = 1)] | ||
| pub retry_count: Option<u16>, |
Contributor
There was a problem hiding this comment.
Why do we need this information here , we already might have this is in intent right?
Contributor
Author
There was a problem hiding this comment.
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.
Aprabhat19
reviewed
Apr 10, 2025
| 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, |
Contributor
There was a problem hiding this comment.
Can we not use self.0 here its not very readable
Aprabhat19
previously approved these changes
Apr 10, 2025
srujanchikke
previously approved these changes
Apr 11, 2025
ShankarSinghC
previously approved these changes
Apr 11, 2025
048295f
srujanchikke
approved these changes
Apr 11, 2025
ShankarSinghC
approved these changes
Apr 11, 2025
Aprabhat19
approved these changes
Apr 11, 2025
pixincreate
added a commit
that referenced
this pull request
Apr 21, 2025
…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 ...
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 --allcargo clippy