Swipelux API चेंजलॉग और रिलीज़ नोट्स

​

जोड़ा गया

• Recipient destinations अब ब्राज़ील में BRL payouts के लिए pix और pix_safe types स्वीकार करते हैं। एक Pix destination किसी Pix key को भुगतान करता है। एक Pix Safe destination ऐसे bank account को भुगतान करता है जिसकी पहचान holder के CPF या CNPJ, bank के ISPB code, branch और account number से होती है। दोनों के लिए customer की Pix capability (pix_pooled) का ready होना ज़रूरी है, और इनके payouts USDC से funded होते हैं और इन पर कोई developer fee नहीं लगती। Recipients और Send funds देखें।
• GET /v3/customers/{customerId}/tasks/{taskId} अब document requirement ID के साथ documentCandidatesFor स्वीकार करता है, साथ ही alternatives वाली requirement के लिए documentAlternativeKey भी। तब response data.documentCandidates में वे files सूचीबद्ध करता है जिन्हें customer पहले ही upload कर चुका है और जो उस requirement को पूरा कर सकती हैं, किसी भी missingMetadata या conflictingMetadata के साथ। File को दोबारा upload करने के बजाय candidate का documentId missing documentMetadata के साथ submit करें। इस query के लिए accounts:read और customers:read ज़रूरी हैं, और invalid selection पर 400 validation_error लौटता है।

​

बदला गया

• GET /v3/webhooks/portal एक portal URL लौटाता है जो एक घंटे बाद expire हो जाता है, Cache-Control: no-store के साथ। जिस API key के पास webhooks:write है, उसके साथ portal endpoint signing secret दिखाता है और endpoints manage करने, deliveries retry करने और उन्हें replay करने देता है। केवल webhooks:read के साथ portal सिर्फ़ deliveries दिखाता है। Webhooks देखें।
• Citi (citibank) केवल business customers को offer किया जाता है। हर business के पास pooled Citi बना रहता है, और named Citi केवल US के बाहर registered businesses को offer किया जाता है। जब किसी customer को Citi offer नहीं किया जाता, तो supported list उसे छोड़ देती है, उसका नाम देने पर 422 capability_institutions_unsupported लौटता है, और जो method केवल Citi offer करता है वह disabled के रूप में list होता है। institutions के बिना request बाकी banks में से चुनती है। मौजूदा applications और accounts में कोई बदलाव नहीं है।
• Named CFSB (cfsb) capabilities केवल US customers को offer की जाती हैं: US में registered businesses और वहाँ रहने वाले individuals। अन्य customers के लिए supported list named CFSB को छोड़ देती है, और उसका नाम देने पर 422 capability_institutions_unsupported लौटता है। institutions के बिना request बाकी banks में से चुनती है। Pooled CFSB, जिन customers का country unknown है, और मौजूदा applications में कोई बदलाव नहीं है।
• Lead Bank (lead_bank) की named ACH, Wire और SWIFT capabilities केवल उन customers को offer की जाती हैं जिन्हें Lead Bank उनके legal form और countries के आधार पर onboard कर सकता है। अन्य customers के लिए supported list lead_bank को छोड़ देती है, और उसका नाम देने पर 422 capability_institutions_unsupported लौटता है। जिन customers को Lead Bank पहले ही onboard कर चुका है, और जिन capabilities की open request में पहले से lead_bank का नाम है, उनके पास यह बना रहता है। मौजूदा applications और accounts में कोई बदलाव नहीं है।
• RTP केवल pooled है। कोई भी bank नई requests के लिए rtp_named offer नहीं करता, इसलिए supported list उसे disabled के रूप में दिखाती है। जिस customer के पास rtp_named नहीं है, उसके लिए इसकी कोई capability request या task preview जो किसी bank का नाम देता है, 422 capability_institutions_unsupported लौटाता है, और institutions के बिना वाला 422 capability_variant_unavailable लौटाता है। Pooled RTP (rtp_pooled) Citi पर offer किया जाता है, इसलिए केवल business customers ही इसकी request कर सकते हैं।
• Individuals और beneficial owners के लिए नई identity document requests constraints.identityMetadataRequired: true set कर सकती हैं, जिससे हर file के लिए documentMetadata में उसका ID number और issuing country ज़रूरी होता है। नई business proof-of-address और owner proof-of-residence requests constraints.maxIssueAgeDays: 90 set कर सकती हैं, जिससे हर file के लिए उसकी issue date ज़रूरी होती है। मौजूदा tasks अपनी requirements बनाए रखते हैं, इसलिए हर task request पर constraints पढ़ें।
• Business registration request के task answer के लिए, जिसका profilePointer /business/registration है, jurisdiction country, registration number और submission date से पहले की formation date, सभी एक साथ ज़रूरी हैं। Request का valueSchema यह rule publish करता है, और अधूरा answer 400 validation_error लौटाता है।
• Hosted verification के बाद, Swipelux किसी structured value, जैसे address या tax identifiers, की profile requirement के hosted answer को केवल तभी स्वीकार करता है जब वह direct answer वाले ही schema और constraint checks पास करता है। अन्यथा requirement open रहती है, और आप उस value को POST /v3/customers/{customerId}/tasks/{taskId}/submissions के साथ submit करते हैं। जिस requirement को Swipelux इस कारण action_required पर लौटाता है, उसमें reviewFeedback.code: hosted_profile_direct_submission_required होता है। जो tasks पहले से satisfied हैं, उनका status बना रहता है। Capabilities और requirements देखें।
• Hosted verification द्वारा rejected task, उस verification decision के बाद में पलटे जाने पर rejected से बाहर आ सकता है। तब वह satisfied हो जाता है, या एक नए revision के साथ action_required हो जाता है, जिसमें वे requirements फिर से open होती हैं जिनका नया decision answer नहीं देता। उन requirements के पहले के submissions rejected ही रहते हैं, इसलिए वे answers फिर से submit करें। v3 पर माइग्रेट करें देखें।
• Recipient destination type अब एक open enum है। इस reference के पहले के versions में इसे closed बताया गया था, इसलिए ऐसे किसी भी client को update करें जो unknown types को reject या drop करता है। Destination responses और destination.status_changed events में अब pix और pix_safe आ सकते हैं, और आगे और types जोड़े जा सकते हैं।
• Recipient create और update requests, nested address सहित, उन fields को 400 validation_error लौटाने के बजाय ignore करती हैं जिन्हें वे define नहीं करतीं। Create request में दूसरे recipient type का name या industry field अब भी 400 लौटाता है, और PATCH /v3/customers/{customerId}/recipients/{recipientId} में type और externalId भी। ऐसा PATCH जिसमें कोई पहचाना गया field न हो, 200 के बजाय 400 validation_error लौटाता है।
• किसी eligible session के लिए verification link, जो केवल documents माँगता है, अब Swipelux-hosted document upload page खोलता है। Link स्वयं नहीं बदलता, और अन्य sessions अब भी hosted verification flow खोलते हैं।
• Individual customers और related-party persons पर employment.occupation अधिकतम 255 characters स्वीकार करता है।
• जब किसी profile value या task answer में Swipelux form link होता है, जैसे RFI, customer request या transfer tracking link, तो POST /v3/customers, PATCH /v3/customers/{customerId}, POST /v3/customers/{customerId}/related-parties, PATCH /v3/customers/{customerId}/related-parties/{relatedPartyId} और POST /v3/customers/{customerId}/tasks/{taskId}/submissions 400 validation_error लौटाते हैं। यह externalId या metadata पर लागू नहीं होता। हर अस्वीकृत value errors[] में code: public_form_link और अपने JSON Pointer के साथ दिखाई देती है, और response कभी भी link को दोहराता नहीं है। इसके बजाय जानकारी स्वयं भेजें। Errors और retries देखें।

​

ठीक किया गया

• Payout quote और transfer responses USDC या USDT source amount को छह decimal places तक रखते हैं, उदाहरण के लिए 4009.71 के बजाय 4009.711365। Fiat amounts दो decimals रखते हैं। जिस payout का stablecoin source amount दो से अधिक decimals वाला है, उसे बनाने या पढ़ने पर अब 500 नहीं लौटता।
• POST /v3/customers/{customerId}/capabilities/{capabilityId}/cancel reference अब cancellation को वैसे ही describe करता है जैसे वह काम करता है। आप एक ready capability cancel कर सकते हैं, stablecoin_transfers capability cancel नहीं की जा सकती, और cancel करने से केवल वही capability समाप्त होती है, जबकि उसके applications अपना status, tasks और approvals बनाए रखते हैं।
• जो capability request या task preview institutions में public institution ID के बजाय bank code list करता है, जैसे citibank के बजाय citi, वह 503 kyc_configuration_unavailable के बजाय उपलब्ध IDs का नाम देते हुए 422 capability_institutions_unsupported लौटाता है।
• किसी ऐसे method के लिए capability request या task preview, जिसे कोई भी bank customer को offer नहीं करता और जिसे supported list disabled के रूप में दिखाती है, 503 kyc_configuration_unavailable के बजाय retryable: false के साथ 422 capability_variant_unavailable लौटाता है, जब तक customer के पास वह capability पहले से न हो।
• documentCandidates अब उन files को list नहीं करता जिन्हें Swipelux किसी completed hosted verification से रखता है और जिन्हें आप पढ़ या download नहीं कर सकते। जो task answer इनमें से किसी का हवाला देता है, वह unknown document की तरह ही 400 invalid_document_reference लौटाता है।

​

जोड़ा गया

• GET /v3/customers अब include=documentRequirements स्वीकार करता है। तब हर customer summary बताता है कि कितने mandatory documents अभी भी बाकी हैं, capability readiness से स्वतंत्र रूप से। इसे include=capabilities,documentRequirements के रूप में combine करें। Customers देखें।
• Merchant panel के Webhooks page में endpoint menu में Replay missed events जोड़ा गया है। यह पिछले 13 दिनों के वे events दोबारा भेजता है जो endpoint को कभी नहीं मिले, और एक ही event को कभी दो बार नहीं भेजता। Webhooks देखें।
• Merchant panel के Settings page में एक Compliance section है। Owners और admins compliance email set कर सकते हैं और चुन सकते हैं कि जब Swipelux किसी customer के बारे में अधिक जानकारी माँगे तो उन्हें emails मिलें या नहीं।
• Merchants अब merchant panel के KYB page पर ही अपनी KYB compliance requests का जवाब दे सकते हैं।

​

बदला गया

• Completed bank intake के बाद customer और related-party updates अब 409 field_conflicts_with_completed_intake नहीं लौटाते। Update save हो जाता है, और हर नया bank application latest profile को अपनी requirements के अनुसार जाँचता है।
• जब किसी capability की मौजूदा bank routing को सुरक्षित रूप से update नहीं किया जा सकता, तो capability requests 409 capability_route_header_conflict लौटाते हैं। Retry करने से पहले Swipelux support से संपर्क करें।
• जब institutions में ऐसा bank हो जिसे capability offer नहीं करती, तो GET /v3/customers/{customerId}/capabilities/{capabilityId}/tasks-preview 422 capability_institutions_unsupported लौटाता है, जैसा capability requests पहले से करते हैं।
• Sandbox में ACH, Wire और SWIFT capabilities केवल JPMorgan Chase पर serve की जाती हैं। जो requests institutions छोड़ देती हैं, वे jpmorgan चुनती हैं, और कोई दूसरा bank देने पर 422 capability_institutions_unsupported लौटता है। Live routing में कोई बदलाव नहीं है। Sandbox में परीक्षण देखें।
• जब simulated case requested status तक नहीं पहुँच सकता, तो sandbox capability status को force करने पर statusReason के साथ 409 capability_status_blocked लौटता है। पहले से लागू हो चुके force को दोहराने पर बिना बदलाव के 200 लौटता है। Sandbox में परीक्षण देखें।
• POST /v3/sandbox/tasks/{taskId}/review उस task के लिए 409 task_not_sandbox_reviewable लौटाता है जिसका स्वामित्व Operations या किसी अन्य workflow के पास है। POST /v3/sandbox/tasks से बने tasks और Swipelux द्वारा collect किए जाने वाले capability intake tasks review योग्य बने रहते हैं। देखें Sandbox में परीक्षण।
• जब account अभी bank पर provision हो रहा हो और आप settlement बदलते हैं, तो PATCH /v3/customers/{customerId}/accounts/{accountId} 409 account_provisioning_unresolved लौटाता है। Provisioning settle होने के बाद retry करें। Errors और retries देखें।
• POST /v3/transfers 409 quote_execution_evidence_conflict लौटा सकता है। नया quote बनाएँ और उसे execute करें। Errors और retries देखें।
• Merchant panel का Pay out drawer पूरी destination details दिखाता है, account numbers और wallet addresses को एक toggle के पीछे mask करता है, और हर payment method के लिए estimated arrival time दिखाता है।
• Merchant panel bank accounts को customer के Payment access tab में शामिल करता है, जिसमें एक tasks card हर bank का नाम बताता है। Documents tab को Profile में ले जाया गया है।
• Merchant panel में named bank account खोलना अब एक ही step है, जो हर bank की currency, methods और onboarding time दिखाता है। Accounts देखें।
• Review के लिए रोके गए bank accounts merchant panel में On hold के रूप में दिखते हैं, साथ में account ID और एक Contact support action।
• एक pending capability अब review_in_progress के बजाय statusReason.code: preparing_submission report करती है, जब Swipelux submission के लिए application तैयार कर रहा होता है और कोई review चल नहीं रहा होता। दोनों codes resolution: wait का उपयोग करते हैं। इनके बीच बदलाव status को pending ही रखता है, इसलिए कोई capability.status_changed event नहीं भेजा जाता। मौजूदा capabilities अपने अगले reevaluation पर नया code अपनाती हैं। Capabilities और requirements देखें।
• Merchant panel में customer के Payment access tab पर Shared methods table, उस pooled method के लिए In review के बजाय In preparation दिखाती है जिसकी capability preparing_submission report करती है।
• किसी capability की applications list अब केवल उसके वर्तमान applications दिखाती है, capability reads (जिसमें GET /v3/customers/{customerId}/capabilities/{capabilityId}/applications शामिल है), capability request responses, और capability.status_changed events में। जिस application को किसी नए application ने replace किया है, वह अब भी GET /v3/customers/{customerId}/applications में दिखता है, जहाँ supersededByApplicationId उसके successor का नाम बताता है। Replace किए गए application के open tasks अब भी capability के openTaskIds में गिने जाते हैं। Capability का status और openTaskIds नहीं बदलते, इसलिए यह बदलाव स्वयं कोई webhook event नहीं भेजता। Capabilities और requirements देखें।

​

ठीक किया गया

• Bank approval से पहले उसी issued account के लिए भेजी गई दूसरी allowPending request अब 500 के बजाय 409 लौटाती है, जो holder.accountId में waiting account बताता है। Bank account जारी करें देखें।
• Capability cancel करने पर अब वे issued account requests बंद हो जाती हैं जो अभी bank approval की प्रतीक्षा में थीं, ताकि उसी bank पर बाद की request नए सिरे से शुरू हो।
• जिस canceled capability के सभी bank cases reject हो गए थे, उसे दोबारा request करने पर canceled से एक ही capability.status_changed event publish होता है।
• किसी bank का पिछला application archive होने के बाद उसे दोबारा request करने पर अब नया application submit होता है।
• Matching capability के ready होते ही recipient destinations जोड़े जा सकते हैं, 409 rail_not_ready लौटाने के बजाय। Recipients देखें।
• Merchant panel का Webhooks page पहली बार खोलने से पहले भेजे गए webhook events अब रखे जाते हैं, ताकि आप उन्हें किसी नए endpoint पर replay कर सकें।
• Merchant panel में task due dates आपके अपने timezone में दिखती हैं, और जब कुछ भी open नहीं बचता तो bank review drawers All requirements submitted दिखाते हैं।

​

जोड़ा गया

• POST /v3/quotes अब crypto-to-fiat payout quote के लिए किसी approved bank route को चुनने हेतु एक वैकल्पिक institutionId स्वीकार करता है। Automatic routing बनाए रखने के लिए इसे छोड़ दें। जो bank payout के लिए उपलब्ध नहीं है, वह 422 bank_not_supported_for_customer लौटाता है, और किसी अन्य quote type के साथ institutionId भेजने पर 400 validation_error लौटता है। Send funds देखें।
• POST /v3/customers/{customerId}/accounts पर issued bank account requests अब account को बिना fallback के एक bank पर pin करने के लिए institution स्वीकार करती हैं, और उस bank का application approval की प्रतीक्षा में रहते हुए request को save करने के लिए allowPending: true स्वीकार करती हैं। allowPending के लिए institution आवश्यक है। Saved requests उन्हें नियंत्रित करने वाला applicationId बताती हैं। Bank account जारी करें देखें।
• Merchant panel में endpoints manage करने के लिए एक native Webhooks page है। Webhooks देखें।
• Merchant panel में named bank accounts, crypto deposits और एक review step के साथ Pay in drawer जोड़ा गया है।
• Merchant panel का Pay out flow source picker में wallet balances दिखाता है, Max amount option जोड़ता है, और एक review step शामिल करता है।
• Merchant panel में customer profiles में Recipients & destinations tab है।
• Task requirements में एक छोटा title heading शामिल हो सकता है। Request का prompt अब भी guidance देता है। Capabilities और requirements देखें।

​

बदला गया

• Pooled Wire routes पर wire pay-in quotes के लिए अब कम से कम $20 आवश्यक है। जो quotes किसी route की न्यूनतम सीमा से कम हैं, या transfer fees cover करने के लिए बहुत छोटे हैं, वे generic quote failure के बजाय 422 amount_not_deliverable लौटाते हैं। Receive funds देखें।
• Webhook portal अब v3 event types को resource के अनुसार group करता है और हर event का payload schema और एक example दिखाता है। Legacy event types एक अलग Legacy group में दिखाई देते हैं और deprecated के रूप में marked हैं। जो endpoints पहले से इनके लिए subscribed हैं, उन्हें ये मिलते रहते हैं; नए subscriptions के लिए v3 event types का उपयोग करें। Webhooks देखें।
• Sandbox top-ups अब transfer.created और transfer.state_changed webhook events emit करते हैं। Sandbox में परीक्षण देखें।
• जब customer के पास पहले से active issued account हो, तो accountProvisioning अब issued report करता है। Capabilities और requirements देखें।
• Merchant panel में bank account details bank logos के साथ एक drawer में खुलते हैं। Accounts देखें।
• Merchant panel money movement को Pay in और Pay out के रूप में label करता है, आपको छह घंटे तक signed in रखता है, और help requests को email द्वारा Swipelux support को भेजता है।
• Direct submission स्वीकार करने वाली intake tasks में, customer profile या uploaded documents से पहले से समर्थित eligible requirements अपने आप in_review में चली जाती हैं। Capabilities और requirements देखें।

​

ठीक किया गया

• Canceled capability को दोबारा request करना अब superseded application records या पुरानी requirements की वजह से fail नहीं होता।
• Retired Fedwire ID के अंतर्गत stored capabilities अब 500 लौटाने के बजाय wire के रूप में पढ़ी जाती हैं।

​

जोड़ा गया

• GET /v3/customers/{customerId}/applications किसी customer के application cases को सूचीबद्ध करता है, साथ में हर case के लिए request की गई capabilities और उसके approval द्वारा cover की जाने वाली capabilities। किसी bank पर एक approval कई capabilities को cover कर सकता है। Retained historical cases supersededByApplicationId के माध्यम से अपने successor की ओर point करते हैं। यह list cursor pagination और updatedAfter को support करती है। Capabilities और requirements देखें।
• POST /v3/customers/{customerId}/capabilities/{capabilityId} responses में case-backed capabilities के लिए selectedApplicationId शामिल होता है। यह उस मौजूदा application case की पहचान करता है जिसे request ने दोबारा उपयोग किया, या उस case की जिसे उसने खोला। Capabilities और requirements देखें।
• GET /v3/institutions और supported-capabilities list द्वारा लौटाए गए institutions में nullable logoUrl शामिल होता है। उपलब्ध होने पर bank branding दिखाने के लिए इसका उपयोग करें, और जब यह null हो तो institution name पर fall back करें। Capabilities और requirements देखें।
• USD SWIFT payouts अब उपलब्ध हैं। SWIFT payouts के लिए कम से कम 100 USD आवश्यक हैं। Merchant panel recipients के लिए SWIFT bank instructions एकत्र करता है। Send funds देखें।
• Issued bank accounts named receiving details के साथ SWIFT पर funds प्राप्त कर सकते हैं। Bank account जारी करें देखें।
• USDT अब ACH और Wire payouts के source के रूप में supported है। Send funds देखें।
• Issued bank accounts settlement wallet में deliver किए जाने वाले stablecoin को चुनने के लिए USDC या USDT का settlement.currency स्वीकार करते हैं, जो wallet account currency से स्वतंत्र है। Wallet की currency में settle करना जारी रखने के लिए इसे छोड़ दें। Bank account जारी करें देखें।
• SWIFT bank accounts और recipient destinations bankCity, bankState, bankPostalCode और bankAddressLine2 स्वीकार करते हैं, साथ ही वैकल्पिक beneficiaryTaxId, beneficiaryPhoneNumber, ifscBranchCode, paymentCode और intermediary bank details भी। Send funds देखें।
• जब bank अलग-अलग ACH और Wire routing numbers देता है, तो issued bank account details में achRoutingNumber और wireRoutingNumber शामिल होते हैं, और receiving bank के लिए bankLogoUrl भी। Bank account जारी करें देखें।
• capability.created webhook events में applicationId और requested या approval का origin शामिल होता है, ताकि आप अपनी request की गई capabilities को approval द्वारा cover की गई capabilities से अलग पहचान सकें। Webhooks देखें।
• Requirement requests एक validation constraints.format declare कर सकती हैं, जैसे http_url, us_ssn, us_ein या bank_industry_classification। Capabilities और requirements देखें।

​

बदला गया

• Merchant panel में bank account creation अब bank selection से शुरू होता है, और bank accounts अलग-अलग ACH और Wire routing numbers दिखाते हैं। Accounts देखें।
• network enum में अब solana शामिल है। यह एक open enum है, इसलिए ऐसे network values को tolerate करें जिन्हें आप नहीं पहचानते। Accounts देखें।
• जिस task की शेष requirements के लिए direct submission आवश्यक है, उसके लिए hosted verification link खोलने पर 409 verification_session_not_allowed लौटता है। इसके बजाय उन requirements को task submission के रूप में submit करें। Errors और retries देखें।
• जिस issued account की provisioning settle नहीं हुई है, उसे archive करने पर 409 account_provisioning_unresolved लौटता है। Provisioning settle होने के बाद retry करें। Errors और retries देखें।
• नई named bank account requests अगले customer refresh की प्रतीक्षा करने के बजाय account बनते ही provisioning के लिए queue हो जाती हैं। Bank account जारी करें देखें।

​

हटाया गया

• नए accounts के लिए pooled SWIFT receiving details अब प्रदान नहीं किए जाते। इसके बजाय named SWIFT receiving details का उपयोग करें। Bank account जारी करें देखें।

​

ठीक किया गया

• Payout transfer reads अब quoted recipient लौटाते हैं।
• किसी मौजूदा ACH account को archive करने के बाद नया ACH account बनाने पर अब 409 नहीं लौटता, और archived pending account requests अब account slot नहीं रोकतीं।
• Local-currency pay-in quotes पर bank fees सही fiat currency में report की जाती हैं।

​

जोड़ा गया

• GET /v3/webhooks/{webhookId} एक single webhook endpoint और उसका events selection पढ़ता है। Webhooks देखें।
• Task requirements अब profile fields के लिए allowedValues और JSON Schema valueSchema publish करती हैं, जिनमें required address fields भी शामिल हैं। Country fields valueType या itemValueType को country के रूप में report करती हैं, जो एक ISO 3166-1 alpha-2 code है। आप inputs और choices को hardcode किए बिना render कर सकते हैं। Capabilities और requirements देखें।
• मौजूदा Tron wallets अब customer के external wallet accounts में USDT भेज सकते हैं, और transfer reads में Tron transactions के लिए block explorer link शामिल होता है। Tron पर नए wallets issue नहीं किए जा सकते। Send funds देखें।
• Task requirements requiredWhen (केवल तब उत्तर दें जब कोई named yes/no answer match करे), profileAssertion (us_person) और ownershipPolicy declare कर सकती हैं, और document requests identityMetadataRequired और maxIssueAgeDays सेट कर सकती हैं। Task answers referenced documents के लिए documentMetadata (idNumber, issuingCountry, issuedOn) स्वीकार करते हैं, और task reads conditionValues में reviewed controlling answers लौटाते हैं। Capabilities और requirements देखें।
• Document requirements acceptedDocumentSets सूचीबद्ध कर सकती हैं, और related-party requirements beneficial_owner के अलावा associated_person या control_person qualification भी मांग सकती हैं। Capabilities और requirements देखें।
• Transfer correction objects अब failed funded payouts को भी cover करते हैं: recover_source_funding compensating action के साथ kind: funding_failure, unknown या reported का recoveryStatus, और USDT credited outputs। Quotes और transfers देखें।

​

बदला गया

• PATCH /v3/webhooks/{webhookId} अब उन legacy event types को स्वीकार करता है जिनके लिए endpoint पहले से subscribed है, ताकि v3 event types जोड़ते समय आप उन्हें बनाए रख सकें। events पूरे selection को replace करता है, इसलिए हर वह event type शामिल करें जिसे आप रखना चाहते हैं। ऐसा legacy event type जोड़ने पर जो endpoint के पास पहले से नहीं था, 400 validation_error मिलता है। Webhooks देखें।
• Recipients और accounts पर bank identifiers को save करने से पहले validate किया जाता है। Recipients देखें।
• जब कोई capability किसी पुराने onboarding model के तहत बनाई गई हो, तो capability requests, task submissions और sandbox status changes अब 500 के बजाय 409 capability_application_stale लौटाते हैं। Errors और retries देखें।
• Public RFI page अब एक continuous form है। यह related people को support करता है और प्रति व्यक्ति एक tax ID एकत्र करता है। Document requirements देखें।
• जब कोई payment bank पर customer की शेष daily या monthly allowance से अधिक होता है, तो quotes और transfers 409 customer_bank_limit_exceeded लौटाते हैं, और जब वह allowance check नहीं की जा सकती, तो 503 customer_bank_limits_unavailable लौटाते हैं। जब कोई payout अपने quote से शुरू नहीं हो सकता, तो transfers 409 payout_execution_unavailable लौटाते हैं। Errors और retries देखें।
• Completed bank intake से conflict करने वाले customer और related-party updates taskId और fields के साथ 409 field_conflicts_with_completed_intake लौटाते हैं।

​

ठीक किया गया

• Canceled capability history पढ़ने योग्य बनी रहती है।
• Merchant panel की transaction list में wire payouts अब सही तरीके से दिखते और filter होते हैं।

​

बदला गया

• POST /v3/transfers और transfer reads अब card checkout pre-selection के लिए paymentMethod के बजाय checkoutMethod का उपयोग करते हैं, और card, apple_pay, google_pay, cash_app, sepa और blik स्वीकार करते हैं। यह list open है और बढ़ सकती है। paymentMethod अब पहचाना नहीं जाता; जो requests इसे अब भी भेजती हैं, उन्हें ऐसे माना जाता है जैसे इसे छोड़ दिया गया हो। sepa और blik card checkout के अंदर के funding options हैं, Swipelux की capabilities नहीं। Receive funds देखें।

​

जोड़ा गया

• POST /v3/transfers अब card quotes के लिए वैकल्पिक paymentMethod (card, apple_pay या google_pay) स्वीकार करता है। जब request की गई method customer और उसके device के लिए उपलब्ध होती है, तो hosted checkout उसी method पर खुलता है, transfer reads request को लौटाते हैं, और quote के amounts और fees अपरिवर्तित रहते हैं। Receive funds देखें।
• GET /v3/customers/{customerId}/capabilities/{capabilityId}/tasks-preview अब supported-capabilities list द्वारा लौटाए गए विशिष्ट banks के लिए tasks का preview करने हेतु institutions स्वीकार करता है। Capabilities और requirements देखें।

​

बदला गया

• Card quotes अब checkout fees और delivered net USDC को दर्शाते हैं। Receive funds देखें।
• Rejected payout quotes generic failure के बजाय एक विशिष्ट problem code लौटाते हैं: quote_amount_out_of_range, quote_volume_limit_exceeded, quote_source_network_unsupported या quote_failed, और जब quote को बाद में retry किया जा सकता है, तो 503 quote_temporarily_unavailable। Errors और retries देखें।

​

ठीक किया गया

• Card quotes अब fee rounding की वजह से fail नहीं होते।
• Questionnaire answers में अतिरिक्त spaces होने पर hosted KYC link दोबारा खोलने से अब 409 kyc_process_conflict नहीं लौटता।
• Merchant panel में अटके हुए passkey withdrawal confirmations अब recover हो जाते हैं।

​

जोड़ा गया

• POST /v3/customers/{customerId}/documents अब storageKey, fileName और type के साथ application/json body भी स्वीकार करता है। storageKey पहले वाले direct-upload flow के माध्यम से park की गई एक ताज़ा customer-scoped reference होनी चाहिए, और upload multipart uploads जैसी ही size और file-signature validation से गुज़रता है। v3 पर माइग्रेट करें देखें।
• GET /v3/customers/{customerId}/documents/{documentId}/download किसी active customer document के लिए download url लौटाता है। URL एक घंटे बाद समाप्त हो जाता है और फ़ाइल को attachment के रूप में serve करता है। Archived, unknown और cross-customer documents 404 लौटाते हैं। Capabilities और requirements देखें।
• ऐसे business के लिए capability request करने पर जिसका कोई beneficial owner नहीं है, अब 503 से fail होने के बजाय उसे जोड़ने के लिए intake task बनती है। जो requests आगे नहीं बढ़ सकतीं वे 422 beneficial_owner_required लौटाती हैं, साथ में declared या कम से कम 25% ownership वाला individual related party जोड़ने के निर्देश। Shareholders, UBOs और control persons देखें।
• Merchant panel की task table अब हर request का subject और capability scope दिखाती है, जिससे आप देख सकते हैं कि compliance request किसे और किस चीज़ को cover करती है। Capabilities और requirements देखें।
• Merchant panel में industry classification fields अब customer profiles और requirement tasks पर searchable NAICS codes प्रदान करती हैं। KYB workflow देखें।
• Bank pay-in instructions में bankName, bankAddress, accountHolderName और accountHolderAddress शामिल हो सकते हैं। इन्हें अन्य bank coordinates के साथ दिखाएँ। Receive funds देखें।
• POST /v3/transfers एक वैकल्पिक redirectUrl स्वीकार करता है, जो card या Apple Pay hosted checkout के बाद customer को आपके app पर वापस लाता है। URL पर पहुँचना completion की पुष्टि नहीं करता; transfer reads या webhooks का उपयोग करें। Receive funds देखें।
• v3 Rule द्वारा बनाए गए transfers origin: rule के साथ transfer reads और lists में दिखाई देते हैं, और अन्य transfers की तरह transfer.state_changed events emit करते हैं। इन्हें GET /v3/transfers?origin=rule से filter करें। Quotes और transfers देखें।
• Customers और related parties पर identity documents sideApplicability (front_only, front_and_back या unknown) स्वीकार करते हैं, और tasks type, number, issuingCountry, issuingRegion, issuedOn, expiresOn और doesNotExpire जैसे identity-document details answers के रूप में एकत्र कर सकती हैं। Capabilities और requirements देखें।

​

बदला गया

• In-progress bank setup से conflict करने वाले bank-detail submissions अब 409 ops_rail_handoff_conflict लौटाते हैं। Documents दोबारा upload करने के बजाय अपने uploaded document IDs रखें और conflict हल होने के बाद वही submission फिर से भेजें। Errors और retries देखें।
• Customer wallets में unannounced stablecoin deposits की न्यूनतम सीमा अब 10 units के बजाय 1 unit है। इससे छोटे deposits अब भी dust माने जाते हैं। Receive funds देखें।
• Webhook configuration अब प्रति environment अलग है। Webhook portal उसी environment के scope में खुलता है जिससे आप उसे request करते हैं, इसलिए sandbox और production endpoints अब settings साझा नहीं करते। Webhooks देखें।
• Merchant panel अब उपलब्ध pay-in methods customer की v3 capabilities से derive करता है, इसलिए account setup केवल वही methods प्रदान करता है जिनका customer हकदार है। Accounts देखें।
• RFI forms अब छोटे, स्पष्ट prompts से qualifying beneficial owners एकत्र करते हैं, और RFI history lifecycle milestones के रूप में दिखती है। Document requirements देखें।
• बिना explicit due date वाली open tasks में अब dueAt डिफ़ॉल्ट रूप से creation के 31 दिन बाद सेट होता है। Capabilities और requirements देखें।

​

हटाया गया

• नए pay-in methods जोड़ते समय merchant panel अब Fedwire की पेशकश नहीं करता। मौजूदा Fedwire accounts पढ़ने योग्य रहते हैं। Accounts देखें।

​

ठीक किया गया

• Customer wallets में unannounced USDT deposits अब अनदेखा होने के बजाय पहचाने और settle किए जाते हैं।
• पहले से submit किया गया evidence अब उसी item की मांग करने वाली अन्य tasks पर भी लागू होता है, इसलिए customers से एक ही document दो बार नहीं मांगा जाता।
• Capability को दोबारा request करने पर पहले से ready bank routes अब discard नहीं होते, इसलिए जारी किए गए account details स्थिर रहते हैं।
• Merchant panel में bank instruction views अब SWIFT addresses और target wallet address सहित पूरे details दिखाते हैं।
• RFI forms अब submission validation errors दिखाते हैं, submit करने से पहले legal form descriptions validate करते हैं, और कई business websites स्वीकार करते हैं।
• अब आप RFI forms में related-person drafts को submit करने से पहले edit कर सकते हैं।
• Canceled compliance requests अब merchant panel की task list में दिखाई नहीं देते।
• Merchant panel में document review statuses फिर से सही दिखते हैं।

​

जोड़ा गया

• Customer-scoped hosted verification और Terms of Service sessions में अब authoritative action object शामिल है। इसके available या unavailable kind का पालन करें; available actions के लिए top-level url और expiresAt fields compatibility mirrors बने रहते हैं। Capabilities और requirements देखें।
• Sandbox wallet top-ups अब transfer IDs लौटाते हैं जिन्हें आप GET /v3/transfers/{transferId} से पढ़ सकते हैं या GET /v3/transfers से सूचीबद्ध कर सकते हैं। वे completed inbound stablecoin deposits के रूप में दिखाई देते हैं। Sandbox में परीक्षण देखें।
• जब किसी transfer के complete होने के बाद उसके funds लौटाए या reverse किए जाते हैं, तो transfer reads में एक correction object शामिल होता है। यह correction का kind, normalized providerStatus, कोई भी providerShortfall, और Swipelux द्वारा लागू किया गया compensatingIntent report करता है। Quotes और transfers देखें।

​

बदला गया

• Cards और Apple Pay के लिए merchant panel का First pay-in walkthrough अब customer के अंतर्गत Polygon wallet की मांग करता है। Walkthrough शुरू करने से पहले वह wallet बनाएँ। Accounts देखें।
• नए requests और public responses method और capability के canonical नाम के रूप में sepa का उपयोग करते हैं। sepa_instant input alias और पहले से stored resources compatible रहते हैं, लेकिन public responses sepa लौटाते हैं। Accounts देखें।
• नए Faster Payments capability, issued-account और quote requests उपलब्ध नहीं हैं। मौजूदा accounts, quotes और transfers पढ़ने योग्य रहते हैं। Accounts देखें।
• KYB का पहला पेज अब representative की जन्मतिथि एकत्र नहीं करता। Shareholders की जन्मतिथियाँ अलग requirement बनी रहती हैं। KYB workflow देखें।
• RFI document references अब image/jpeg के साथ MIME alias image/jpg भी स्वीकार करते हैं। Document requirements देखें।
• Merchant panel में task history अब revision counters के बिना पढ़ने योग्य audit trail दिखाती है। Capabilities और requirements देखें।
• Quotes और transfers अब कोई भी पैसा move होने से पहले capability की supported directions check करते हैं। किसी capability का उस direction में उपयोग करने पर जिसे वह support नहीं करती, 422 capability_direction_unsupported लौटता है, और wallets के बीच moves के लिए stablecoin_transfers capability आवश्यक है। Errors और retries देखें।

​

हटाया गया

• Merchant panel अब नए UAEFTS account setup की पेशकश नहीं करता। मौजूदा UAEFTS accounts पढ़ने योग्य रहते हैं। Accounts देखें।

​

ठीक किया गया

• Reviewer द्वारा नया document drop जोड़ने पर RFI forms मौजूदा entries को बनाए रखते हैं, इसलिए दोबारा submit करने पर पहले दिए गए answers नहीं खोते।
• Merchant panel valid links हटाए बिना available actions से hosted compliance sessions को फिर से शुरू करता है।
• Hosted Terms of Service links अब API द्वारा लौटाए गए हर task scope के लिए काम करते हैं।
• Merchant panel में Payment Access request करने के बाद, वह पहले के request की task के बजाय उसी request से लौटी intake task खोलता है।
• Merchant panel का KYB demo अब वर्तमान required fields पूछता है।
• Source wallet को destinationId के रूप में दोबारा उपयोग करने वाला quote अब provider work शुरू होने से पहले actionable 422 quote_direction_invalid details लौटाता है। Quotes और transfers देखें।
• API malformed query-string encoding को चुपचाप normalize करने के बजाय 400 error से reject करता है। Errors और retries देखें।
• POST /v3/customers/{customerId}/documents अब empty, non-multipart या malformed request bodies को 400 error से reject करता है।

​

जोड़ा गया

• OpenAPI स्पेसिफिकेशन में v3 Problem Details कैटलॉग प्रकाशित किया गया ताकि इंटीग्रेटर्स सीधे स्कीमा से एरर रिस्पॉन्स को मैप कर सकें। देखें Errors।
• v3 account webhook events में customerId जोड़ा गया, जिससे आप बिना फॉलो-अप रीड के account गतिविधि को स्वामी customer से जोड़ सकते हैं। देखें Webhooks।
• Merchant panel में पूर्ण V3 individual profile field कवरेज, ताकि onboarding operators v3 API के माध्यम से एकत्रित प्रत्येक KYC फ़ील्ड की समीक्षा और संपादन कर सकें। देखें Customers।
• v3 डेवलपर माइग्रेशन गाइड प्रकाशित की गई। देखें v3 पर माइग्रेट करना।

​

बदला गया

• Customer और account country codes अब लिखने के समय निर्दिष्ट ISO 3166-1 alpha-2 मानों के रूप में मान्य किए जाते हैं। रीड लीगेसी स्टोर किए गए मानों को सहन करते हैं ताकि मौजूदा रिकॉर्ड्स रिज़ॉल्व होते रहें। देखें Accounts और wallets।
• USDC उपलब्धता अब गंतव्य नेटवर्क के अनुसार सीमित है, इसलिए quotes और transfers केवल उन नेटवर्क्स पर USDC प्रदान करते हैं जिन्हें गंतव्य वास्तव में समर्थन करता है।
• हर onboarding flow के लिए अब Swipelux Terms of Service आवश्यक है। मौजूदा sessions resumable रहते हैं। देखें Customers।
• Capability.ready entitlement की स्वीकृति रिपोर्ट करना जारी रखता है। Account जारी होने को not_applicable, not_started, in_progress, issued, या failed के रूप में ट्रैक करने के लिए accountProvisioning का उपयोग करें। देखें Capabilities और requirements।
• iPhone से HEIC अपलोड अब पहचान और पते के दस्तावेज़ के रूप में स्वीकार किए जाते हैं।
• किसी customer या related-party field को clear करने पर, जिसकी किसी open task को अब भी आवश्यकता है, अब retryable conflict के बजाय blocking taskId और fields के साथ 409 field_required_by_open_task लौटता है। उन fields को बदलने से पहले task को complete या cancel करें। देखें Errors और retries।

​

ठीक किया गया

• उपभोग किए गए quote को पुनः निष्पादित करने पर अब जेनेरिक एरर के बजाय 409 quote_execution_consumed लौटता है। देखें Quotes और transfers।
• Transfer list reads और quote amount reads अब बड़े ऐतिहासिक परिणामों पर 500 नहीं देते।
• Concurrent KYC redirects अब 404 के बजाय conflict लौटाते हैं, इसलिए retries साफ़ तरीके से हल होते हैं। Hosted redirects अब बीच में rollback नहीं होते, और KYC links resumable रहते हैं।
• व्यक्तिगत customers के लिए related-party reads अब 404 नहीं देते।
• अमान्य wallet fields वाले KYB submissions submission से पहले reject किए जाते हैं, और विफल synchronization अब merchant panel में success के रूप में रिपोर्ट नहीं होता।
• Merchant panel में requirement tasks अब submit किए गए responses को complete दिखाते हैं, terms actions को अलग से ट्रैक करते हैं, duplicate document text हटाते हैं, शुरू किए गए KYC sessions को पूरा होने तक pending रखते हैं, और stale tasks को requirements दृश्य को तोड़े बिना संभालते हैं।
• Merchant panel में verification link पंक्तियाँ अब प्रत्येक पंक्ति पर Open क्रिया दिखाती हैं, और प्रत्येक task link requirements दृश्य में रेंडर होता है।