How can I get this settlement_id through an alternative to the old interface /v1/{location_id}/settlements

[danielyhsu]

How can I get this settlement_id through an alternative to the old interface /v1/{location_id}/settlements.

I couldn’t find the settlement_id returned by the original /v1/{location_id}/settlements interface in the return value of ListPayouts and GetPayout and ListPayoutEntries mentioned in the migration guide

This value is very important for our background application, but now that the /v1/{location_id}/settlements interface has been deactivated, our application is in a downtime and it is urgent to find an alternative interface modification.

Please ask the staff of Square platform to answer my question as soon as possible. The situation is urgent, thank you very much!

[Bryan-Square]

The ID schema for settlement_id and payout_id aren’t the same. You cannot directly map a V1 settlement_id to its corresponding payout_id in the V2 Payouts API. If your application is syncing historical payout records, it might have synced a payout under a different ID with the Settlements API.

[danielyhsu]

Thank you very much for your reply!

As a programmer who is using Square platform for development for the first time, the knowledge of business is not very familiar. Excuse me, may I ask you the following questions?

Question1: The old interface /v1/{location_id}/settlements returns settlement_id, which means what behavior for what scenario happened?

Question2: Does the same behavior happen at the business level with the old interface /v1/{location_id}/settlements returning settlement_id and the new interface /v2/payouts returning payout_id? In the same sense?

Question 3:

Let me first describe the steps I envision for the API:

1. If I first get payout_id through the new interface /v2/payouts

2. I then use payout_id as a parameter and use a second new interface, /v2/payouts/{payout_id}/payout-entries, to return payment_id.

3. The order_id is then accessed through the third new interface /v2/payments/{payment_id}, using payment_id as a parameter

4. I get the id and transaction_id of tenders through the old interface /v2/locations/{location_id}/transactions, which correspond to the order_id and payment_id obtained in the previous steps
   

   

The third question I want to ask is:

As long as the id under tenders obtained in step 4 matches the order_id obtained in the previous step, and the transaction_id under tenders obtained in step 4 matches the payment_id obtained in the previous step, The system has produced settlement_id, right? The new interface, /v2/payouts, uses payout_id instead of settlement_id. Does the creation of settlement_id and the creation of payout_id imply the same behavior in the same application scenario?

I really look forward to your professional reply, thank you very much!

[danielyhsu]

I exported Transaction data from Seller Dashbord.

A screenshot of the Excel document is as follows:

In fact, all I had to do was get the value of the [Vibration ID] field in the Excel document I exported. The value in the [posome ID] field corresponds to settlement_id from the old interface /v1/{location_id}/settlements. Is there another solution?

[danielyhsu]

I have another question, currently our background application uses connect-2.20191120.0.jar.

After I logged in Developer Dashbord, the Production API version was displayed as 2018-12-12 (58 versions behind).

May I ask, if we change the Production API version on Developer Dashbord to the latest version, will it affect our current background program to access other interfaces? I am going to upgrade the Production API version on Developer Dashbord to the latest 2023-08-16 and then upgrade my background program. Is it OK to do this?

[danielyhsu]

I have another question, currently our background application uses connect-2.20191120.0.jar.

After I logged in Developer Dashbord, the Production API version was displayed as 2018-12-12 (58 versions behind).

May I ask, if we change the Production API version on Developer Dashbord to the latest version, will it affect our current background program to access other interfaces? I am going to upgrade the Production API version on Developer Dashbord to the latest 2023-08-16 and then upgrade my background program. Is it OK to do this?

[danielyhsu]

I look forward to your professional reply to each of my questions. Thank you very much!

[Bryan-Square]

At the business level if a payout_id is returned then there was an attempt to send funds to the linked bank account. The same is true with the settlement_id.

Please note that you shouldn’t be using the Transactions API. Those endpoints are deprecated and will be retired in the future. All the information that’s returned in the Transaction API is available in the Orders API and Payments API.

As for updating the API version we recommend that you test by overriding the default by explicitly specifying an API version in the Square-Version header in your request. This feature enables you to test different API versions.

curl https://connect.squareup.com/v2/payments \
  -H 'Square-Version: 2022-12-14' \
  -H 'Authorization: Bearer {ACCESS_TOKEN}' \
  -H 'Content-Type: application/json'

[danielyhsu]

Thank you very much for your reply. Your reply gave us a lot of help. If we have any questions later, we will consult you again. Thank you again!

[danielyhsu]

How can I get the latest JAR package?

<dependency>
	<groupId>com.squareup</groupId>
	<artifactId>connect</artifactId>
	<version>2.20191120.0</version>
	<scope>compile</scope>
</dependency>

[Bryan-Square]

You’ll need to target the latest version of the SDK to update the SDK.

[danielyhsu]

Thank you very much for your help.

I have found an alternative solution. By consulting your customer service staff, payout_id has the same business meaning as settlement_id, so I use payout_id instead of settlement_id.

Thank you again for your patient reply.

slpo via Square Developer Forums <[email protected]> 于 2023年9月30日周六 上午1:09写道：