Highway Delite Logs Submission - Buyer App

[highwaydelite]

The logs being submitted include:

Flow 1: Station Code
Flow 2: Cancel Flow
IGM Logs
RSF Logs

[gitguardian]

⚠️ GitGuardian has uncovered 2 secrets following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

Since your pull request originates from a forked repository, GitGuardian is not able to associate the secrets uncovered with secret incidents on your GitGuardian dashboard.
Skipping this check run and merging your pull request will create secret incidents on your GitGuardian dashboard.

🔎 Detected hardcoded secrets in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
13810658	Triggered	Generic High Entropy Secret	235c231	TRV11/HighwayDelite/Flow1 (Booking flow)/on_status.json	View secret
7620759	Triggered	Generic High Entropy Secret	05785fd	TRV11/HighwayDelite/Flow1 (Station code flow)/on_cofirm.json	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secrets safely. Learn here the best practices.
3. Revoke and rotate these secrets.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}

[sourabhsaini11]

@highwaydelite, please get the below issues fixed
common_issues

• tag BUYER_FINDER_FEES_TYPE is missing in BUYER_FINDER_FEES tag-group
• virtual_payment_address shouldn't be present if SETTLEMENT_TYPE is NEFT

search1

• payment object is missing

search2

• BAP URL mismatch in /search1 and /search2
• Timestamp for /on_search_1 api cannot be greater than or equal to /search_2 api

select

• BAP URL mismatch in /search2 and /select
• Timestamp for /on_search api cannot be greater than or equal to /select api

init

• BAP URL mismatch in /init and /select
• Timestamp for /on_select api cannot be greater than or equal to /init api

confirm

• BAP URL mismatch in /confirm and /init
• Timestamp for /on_init api cannot be greater than or equal to /confirm api

status

• BAP URL mismatch in /confirm and /status
• Timestamp for /on_confirm api cannot be greater than or equal to /status api

cancel(confirm)

• Timestamp for /cancel(confirm) api is same as timestamp for cancel(soft)

[JyotiSharma0711]

RSF logs

Please submit success flow

"receiver_recon":

• "/message/orderbook/orders/0/payment/@ondc1org1return_window must match format "duration"",
• "/message/orderbook/orders/0/payment/@ondc1org1settlement_window must match format "ISO8601 format"",
• "/message/orderbook/orders/0/payment/@ondc1org1settlement_details/0/settlement_ifsc_code must match pattern "^[A-Z]{4}0[A-Z0-9]{6}$"",
• "context timestamp should be greater than created_at"

on_receiver_recon

• "context.city code mismatch"
• "message.order.message is not defined according to status code"

@highwaydelite

[amitsinha07]

@highwaydelite

Feedbacks for IGM

Issue

• Message/Issue/Sub-Category**: Must be equal to one of the allowed values.
• Organization's name in the /issue API in message/issue/issue_actions/complainant_actions/[0] mismatched with the BAP ID.

issue_close

• Message/issue/issue_actions/complaints_actions/0/updated_by/org does not match with bap_id.
• Message/issue/issue_actions/complaints_actions/1/updated_by/org does not match with bap_id.
  • The timestamp of updated_at of issue_close and issue calls cannot be the same.
  • message/issue/updated_at and created_at cannot be the same in the issue_close call.

---

on_issue

• Timestamp between the issue and on_issue call is incorrect.
• issue and on_issue is wrong and around "P10D".
• updated_at in the on_issue call is incorrect relative to created_at.

---

on_issue_status

[NOTE]: This is on_issue_status not on_issue_close

• Timestamp between the issue and on_issue call is incorrect.
• Cascaded level's updated_at is incorrect.
  Resolution Provider: Should not be present in respondent_actions.

---

on_issue_status_unsolicited

• If issue is resolved in on_issue_status call, then there is no need to send unsolicited call.

[highwaydelite]

@sourabhsaini11 @amitsinha07 please check the updated TRV11 and IGM flows

[highwaydelite]

@JyotiSharma0711
since we are using RSF mock server, we are unable to generate the complete success flow logs. Irrespective of receiver_recon payload, on_receiver_recon responding with same dummy response It contains both success and correction records.

[JyotiSharma0711]

@highwaydelite
Improvise your receiver_recon and for success flow we can connect please share your available time

[highwaydelite]

@JyotiSharma0711 Can we connect at 3 pm today

[sourabhsaini11]

@highwaydelite, please fix below issues as well for transactional logs
search_1

• collected_by is missing

on_confirm, on_status, on_cancel

• tags MANDATORY_ARBITRATION & COURT_JURISDICTION are missing in SETTLEMENT_TERMS tag-group

on_cancel

• status should be CANCELLED for on_cancel(confirm) call

Soft cancel pair-calls are missing

[sourabhsaini11]

@highwaydelite, kindly upload the fixed logs for 2.0.0 'cause 2.0.1 is not supported by other Seller NP's as of now.

[highwaydelite]

@sourabhsaini11 fixed the issues you mentioned. please check the updated logs.

[amitsinha07]

@highwaydelite

Feedbacks for IGM

Issue

Context timestamp: Should be greater than or equal to created_at and updated_at in the issue.

On Issue Status

Respondent Actions:

• message/issue/issue_actions/respondent_actions/1/respondent_actions - Object is missing, and the complaint is not "Resolved'.
  Resolution Provider:
• message/issue/resolution_provider/respondent_info/organization/org/name - Domain name is missing

[JyotiSharma0711]

TRV11/HighwayDelite/RSF

RECEIVER_recon

• message/orderbooks/order/0/settlements_reference_no- (should not be for all settlements).
• message/orderbooks/order/0/settlements_id- (should not be for all settlements).
• message/orderbooks/order/0/transaction_id- (should not be for all settlements)
• Message/orderbooks/orders/0/invoice_no- should not be matched in receiver_call.(for 3 and 4 settlements call).

[highwaydelite]

@JyotiSharma0711 please check updated RSF logs

[sourabhsaini11]

@highwaydelite, please update IGM logs as well

[JyotiSharma0711]

TRV11/HighwayDelite/RSF

Receiver_recon

context timestamp should be greater than updated_at.
message/orderbook/orders/0/updated_at and created_at has a big time difference

[highwaydelite]

@amitsinha07 Please check the updated igm logs

[highwaydelite]

@JyotiSharma0711 please check the updated RSF logs

[sourabhsaini11]

@highwaydelite, kindly resolve below issues
search_1

• tag SETTLEMENT_BASIS should be sent by the seller first hence shouldn't be part of /search_1 call

init

• tags MANDATORY_ARBITRATION & COURT_JURISDICTION are missing in SETTLEMENT_TERMS tag-group

confirm

• bank_account_number & bank_code are missing at payments.params

on_status

• updated_at shouldn't be same as on_confirm's updated_at

[JyotiSharma0711]

@highwaydelite approve for RSF 1.0.0

[amitsinha07]

@highwaydelite

issue_close

• issue_close api call is missing

[highwaydelite]

@amitsinha07 added issue_close api. please check

[highwaydelite]

@sourabhsaini11 Isn't it possible for the updated_at timestamps of on_confirm and on_status to be the same if there's no update to the ticket? During testing with Pramaan, We are getting same timestamp for updated_at of both on_confirm and on_status api's.

[sourabhsaini11]

@highwaydelite, if the payload is not getting changed b/w on_confirm & on_update then the updated_at timestamp can remain same

[highwaydelite]

@sourabhsaini11 you commented this

on_status
updated_at shouldn't be same as on_confirm's updated_at

It is not necessary right? when the ticket is not updated.

[highwaydelite]

@sourabhsaini11 can you please address my query

[highwaydelite]

@sourabhsaini11 please check the updated logs