Seller Forums

Results for "문페이 【 @MOONPAY_CALL 】 안전PG 국민은행 경남가상계좌 가상계좌api"

(20 results)
user profile
Seller_xTKkKv7o6tF0T
user profile
News_Amazon
user profile
Seller_C2zA2RIHD4O2L
replied
user profile
Seller_iUcF35YSDwxDs
user profile
Seller_8hQgfj6OVZYse
replied
user profile
Seller_eai8H3vTLkhVC
replied
user profile
Seller_5N18Y9Oic1CDD
replied
user profile
Seller_ZyGdB49sb7An4
replied
user profile
Seller_EP955GEvoWCZw
user profile
Seller_WDBlM63N2MqW9
replied
Sort by
RecommendedLatest activityRecently createdMost viewedMost voted
Filters
Date/timeAll TimePast dayPast weekPast monthPast 3 monthsPast yearDate range
Quick filters
Discussions
Categories
Tags
Tags will populate based on category selection

Results for "문페이 【 @MOONPAY_CALL 】 안전PG 국민은행 경남가상계좌 가상계좌api"

(20 results)
user profile
Seller_xTKkKv7o6tF0T
user profile

Hello,

As we deliver heavy and bulk furniture the delivery to offmainland is extremaly expensive. Is there any smart way to block the delivery there? I know it cannot be done thourgh amazon set ups but maybe some trick thourgh API etc?

0 votes
0 votes
7 views
1 reply
Latest activity
user profile
News_Amazon
user profile

We’ve heard your feedback about how reports that are only based on payout timing have made accrual reconciliation more difficult, especially when some transactions are deferred.

We’re gradually rolling out updates to the Date Range Transaction and Summary reports for the following stores: Belgium, France, Germany, Ireland, Italy, the Netherlands, Poland, Spain, Sweden, India, Egypt, Saudi Arabia, Türkiye, the United Arab Emirates and the UK. This rollout began on March 23, 2026, and it will continue until May 31, 2026.

This change applies to the following users:

  • Sellers who are subject to delivery-date-based reserve policies
  • Developers who access transaction reports through the reports API

The updated reports will provide a clearer view of accrued earnings for month-end reconciliation and financial reporting.

By May 31, when you request a Transaction or Summary report for a period beginning on January 1, 2025, you’ll notice three key improvements:

  • All posted transactions are in one place. Your reports will include both transactions that have already been released to your balance and transactions that have been deferred under delivery-date-based policies. You must no longer download separate deferred transaction reports to view deferred activity.
  • Activity is indexed by the posted date. The Date/Time column in Transaction reports will reflect the transaction posted date, rather than the release date, or the payout eligibility date. This posted date provides a more consistent view of activity during the period that you select.
  • You have clear visibility into deferred versus released statuses in the same report. There will be a new column in Transaction reports that shows whether a transaction has been deferred or released. An additional column, Transaction Release Date, will indicate when the transaction was released. If a transaction remains deferred, the release date field will be blank.

If you have existing integrations with third-party financial systems, we recommend that you update your mappings or scripts. Note that reports for periods before January 1, 2025, will continue to follow the prior format. We plan to roll out similar reporting updates for additional stores by June 30, 2026.

To view your reports, follow these steps:

  1. Go to Payments and select Reports Repository.
  2. Under Account type, select All (Unified Reports).
  3. Under Report type, select Summary or Transaction.
  4. Set the start date in the Reporting date range as January 1, 2025, or later.
  5. Click Request report.

1 vote
0 votes
66 views
1 reply
Latest activity
user profile
Seller_C2zA2RIHD4O2L
replied
user profile

But the carrier account isn't ours; we use Amazon's own account because you force us to. Therefore, if there are errors, Amazon should investigate; otherwise, they are just as guilty as the carriers. And once again, this problem isn't just with Evri; there are also records from DPD, which suggests that it's Amazon's API that's faulty. If nothing is done, I think sellers should unite and sue Amazon, a multi-billion dollar company that charges sellers more and more fees and disregards them.

1 vote
0 votes
0 views
55 replies
Latest activity
user profile
Seller_iUcF35YSDwxDs
user profile

Hi all,

I wanted to raise a serious issue we’ve recently experienced, partly to document it for others, and partly in the hope that a moderator can escalate this internally.

Context

We are a high-volume UK used book seller, and all of the affected inventory was used stock only — we do not list these items as new.

What happened

We ran a bulk update via the SP-API to change shipping templates on our FBM used book listings (~10,000 SKUs).

API used: putListingsItem (PUT)

Intent: update merchant_shipping_group only

We did NOT include condition_type in the payload

Following this update, a large number of listings were surfaced on Amazon as “New”, despite our internal data still showing them as used.

Timeline / Mitigation

The issue was not immediately apparent because we experienced a noticeable increase in sales following the update, which we initially attributed to improved shipping settings.

Once we identified that listings were incorrectly being surfaced as “New”, we acted immediately:

Placed the account into holiday mode to prevent further orders

Investigated and identified the root cause

Implemented a fix (migrated to PATCH requests)

Began correcting affected listings

By this point, approximately 600 orders had already been placed under the incorrect condition display.

Amazon’s response (important)

In Case ID 12422628992, Amazon has confirmed:

PUT replaces attributes and drops anything omitted

Because condition_type was not included, it was effectively removed

Listings then defaulted/surfaced as New

The API returned 200 ACCEPTED with no warning or validation error

There are currently no safeguards in place to prevent this

So to be clear — this is confirmed platform behaviour, not speculation.

Impact

As a direct result:

Customers purchased items believing they were New

They received correctly described used books from our inventory

This led to:

Negative feedback

Returns

Refunds

Return postage costs

Account health impact

Example feedback:

“I ordered a new book and received a used one”

“Advertised as new but looked worse than a library book”

“Ordered NEW and received a damaged used copy”

Current situation

We’ve fixed our integration (now using PATCH)

We are correcting listings

API support have been helpful in explaining the cause

However:

Seller Support is refusing to remove feedback

No reimbursement is being offered

The position is essentially: “feedback reflects customer experience”

The problem

The customer experience was incorrect because:

Amazon displayed the wrong condition at the point of sale

Given we only sell used inventory, this was not a listing or stock error on our side.

So we are in a position where:

Amazon acknowledges the root cause

But the seller absorbs all consequences

Financial impact

So far:

Dozens of refunds issued

Return postage costs incurred

Outbound shipping losses

Current estimated impact is already £500+ and rising as returns continue.

Why I’m posting

Warning to other sellers/developers

If you are using putListingsItem, be extremely careful

Omitting attributes like condition_type can silently alter listings

Request for moderator escalation

There is a clear gap between:

acknowledged platform behaviour

and seller-impact resolution

Request

Could a moderator please review and escalate this internally?

Specifically:

Whether feedback caused by incorrect condition display can be removed

Whether losses directly caused by this behaviour can be reimbursed

Whether safeguards are being considered for this type of scenario

Happy to provide:

Case ID (12422628992)

Order IDs

Transaction breakdowns

API logs

Thanks in advance,

0 votes
0 votes
22 views
3 replies
Latest activity
user profile
Seller_8hQgfj6OVZYse
replied
user profile

Hi @Seller_iUcF35YSDwxDs,

I'm following up on Ken's behalf. The escalation team has reviewed your request, and determined that you were provided correct information that the feedback is not eligible for removal. Amazon removes feedback only for the reasons outlined on the Can Amazon remove customer feedback? page.

Additionally, losses as a result of using the incorrect operation are not eligible for reimbursement by Amazon, however your feedback about the API has been taken into consideration.

Thanks for your understanding.

Regards,

- Manny

0 votes
0 votes
0 views
3 replies
Latest activity
user profile
Seller_eai8H3vTLkhVC
replied
user profile

We’ve had the exact same issue this week and now we’ve lost Prime despite many tickets opened with seller support to state there is clearly an issue Amazons API connection or a technical issue.

No communication from the seller support team, no contact from the SFP team. Just a big suspension in our peak season.

0 votes
0 votes
0 views
4 replies
Latest activity
user profile
Seller_5N18Y9Oic1CDD
replied
user profile

you can change that through amazon sp-api or some 3rd party tools that use it

google for hopted. might help here particularly with local-language text on EU listings

0 votes
0 votes
0 views
6 replies
Latest activity
user profile
Seller_ZyGdB49sb7An4
replied
user profile

Hello @Seller_b1uMRg2cAnaOX,

Here are a few steps you can try:

  • Disconnect and reconnect your Amazon store integration in Click & Drop (Settings > Integrations)
  • Check for special characters or emojis in your product names/bundles, as these are not supported and can cause import issues
  • Verify your integration hasn't been auto-disabled — Royal Mail disables Amazon integrations that haven't processed orders within 30 days
  • Contact Royal Mail Click & Drop support directly to report the batching delay, as they can check the API connection health on their end

Have you already contacted seller support regarding this situation? If yes, please share your latest case ID so we can look into it further.

— Angie

0 votes
0 votes
0 views
2 replies
Latest activity
user profile
Seller_EP955GEvoWCZw
user profile

Hi,

We are facing some major issues reagarding the Vaild Tracking Rate metric.

Most of our orders are failing VTR Critera 4 recently but we have tired everything and neither Amazon or Linnworks support are able to support us.

I have seen other people also reporting same issue regarding VTR but I'm intreasetd in seeing if anyone else is using Linnworks and if there is any suggestions that can help fix this if its an intergartion problem between Linnworks and Amazon, which I dont think there is. We have tried using diffrent vendor names and shiping service names like Parcel Next Day but still doesnt work

Is this a problem between carrier API and Amazon or is this between the dispatch information sent from Linnworks to Amazon?

Please if anyone can shed some light on this issue

0 votes
0 votes
104 views
4 replies
Latest activity
user profile
Seller_WDBlM63N2MqW9
replied
user profile
Sunday Delivery
by Seller_WDBlM63N2MqW9

I have had same response word for word.

Ive also sent them the following

Please also note your OTDR Policy also sates the following

OTDR exemptions

Orders will have no negative effect on your OTDR when fulfilled using all three of Amazon’s automation tools:

1. Shipping Settings Automation (SSA) enabled on shipping templates

2. Automated Handling Time (AHT) enabled on your account OR a 0–1-day default handling time enabled

3. Buy shipping labels through Manage Orders or Shipping API, or select multi-channel integrators with access to Buy Shipping.

This means any orders shipperd via their buy shipping isnt counted, and all primes have to be purchased via buy shipping

1 vote
0 votes
0 views
13 replies
Latest activity