MANGOPAY CardRegistration JavaScript Kit is a client library designed to take care of the card registration process.

https://github.com/MangoPay/cardregistration-js-kit

When you try to view a card you now get as response to the field CardProvider: CB even it is not.

Our tokenization server will assign the correct card provider to the API in June. The cards already registered will stay with the card provider "CB", but the new once will be correctly assigned.

Dear Partner,

As you probably notice, a vulnerability has been discovered into OpenSSL. OpenSSL is supposed to protect sensitive data as it travels back and forth. The bug is called "heartbleed" and it compromised the security for a lot of website worldwide.

Please find more details below: http://www.circl.lu/pub/tr-21/ http://www.us-cert.gov/ncas/alerts/TA14-098A http://heartbleed.com/ http://www.cvedetails.com/cve/CVE-2014-0160/

Here is a vulnerability test : http://filippo.io/Heartbleed/

As your partner MANGOPAY recommends to update as soon as possible:

• Openssl library.
• Apache with modssl, spdy.
• Nginx with OpenSSL mods.
• And don’t forget to restart your webserver app (apache restart or nginx) Microsoft products are not affected.

You should treat all private keys as completely compromised if your openssl library is vulnerable.

We hope this was helpful information for you and you could solve that asap. Best Regards, Your MANGOPAY Team

MANGOPAY SDK has been updated last week.

https://github.com/MangoPay

• ‘Empty body’ errors

This error is often due to a syntax error. We also pushed a fix so you should get less and less this king of error.

• ‘LegalRepresentativeAddress’ field in ‘users/legal’

The ‘LegalRepresentativeAddress’ field in the ‘users/legal’ object did not keep the value sent, it remained at ‘null’. We pushed a fix to retrieve the values sent.

• New error specification for KYC documents

If the Type of a document sent is not allowed for the associated user, before you received this error:

{

"Message": "Internal Server Error", "Type": "other", "Id": "d36a2340-2b43-482e-bba4-8b505bbb2a84", "Date »: 1385569350, "errors »: null }

Now, for this case, you are receiving this error:

{ "Message": "Error wrong type of document", "Type": "wrong_document_type" "Id": "f41983fb-a2c5-40fc-81a2-14c9fb58f207" "Date"": 1400675136 "errors": {error: "Document [IDENTITY_PROOF] is not valid for [LEGAL_PERSONALITY]"} }

• New error specification for KYC documents

If the Type of a document sent is not allowed for the associated user, before you received this error:

{ "Message": "Internal Server Error", "Type": "other", "Id": "d36a2340-2b43-482e-bba4-8b505bbb2a84", "Date »: 1385569350, "errors »: null }

Now, in this case, you are receiving this error:

{

"Message": "Wrong Type: ‘Document_Type_Variable’ is only used for legal users", "Type": "other", "Id": "d36a2340-2b43-482e-bba4-8b505bbb2a84", "Date": 1385569350, "errors": "Wrong_document_type" }

• Serbian CountryOfResidence or Nationality is now available

Previously Serbian (ISO code RS) was throwing an error, this has now been fixed.

• More information about refunded PayOuts

If a successful PayOut is later refunded back to the wallet, more information is now provided in the GET /Refunds/:RefundId call where you’ll find a new object called RefundReason, for example:

RefundReason: { RefundReasonMessage: “Mangopay has been told this account has now been closed” RefundReasonType: “BANKACCOUNT_HAS_BEEN_CLOSED” }

Also, we’ve added three new hooks PAYOUT_REFUND_CREATED, PAYOUT_REFUND_SUCCEEDED, PAYOUT_REFUND_FAILED to allow you to receive notifications about these three new events.

• KYC info is now correctly showing for users

When viewing a user’s info with GET /Users/:UserId, the KYC properties ProofOfAddress (Natural), ProofOfIdentity (Natural), ShareholderDeclaration (Legal), Statute (Legal), ProofOfRegistration (Legal) are now correctly completed if the property has been successfully validated.

• PAYIN_REFUND_CREATED hook is now available

There was a previous problem with the PAYIN_REFUND_CREATED hook which wasn’t triggering correctly but this is now fixed.

• BIC has become optional while creating a bank account

You can now create Bank Accounts only with the IBAN (law decision applied from the 1st of August 2014)

• The error 500 "StructureMap Exception Code: 202 […]" has been fixed

• KIT JS on ie8 has been fixed

• Next release scheduled for the beginning of September

In order to avoid fraud issues and for legal and security purpose the 3D secure will now start from 101€ by default in production and sandbox environment. For anti-fraud matter the previously amount of 250€ was judged too hight for our security policy.

If you want to activate the 3DS for lower amounts than 100€ you can change the Secure mode field] and put it as FORCE.

The Mangopay team is glad to announce to our German clients that the local payment methods ELV, SOFORT and GIROPAY are now available in v2!

• New German payment methods ELV, SOFORT, GIROPAY

These work much like a normal web PayIn – you can find the detailed description in our online doc .

• **New KYC lists

It is now possible to see a list of KYC documents submitted for a user, and their status etc. This same list is also available more globally for the all KYC documents submitted for your ClientId across all users (more info)

• **Custom sorting for lists

All lists (list of wallets or cards, list of transactions for a wallet or user, list of KYC docs for a user or client) can now be sorted by descending order instead of the default ascending. You can also choose by which field you would like to sort (CreationDate, ExecutionDate etc)

• **Add a custom wire reference for PayOuts

You can add your own reference for PayOuts – this is the reference that will show along with your ClientId on your user’s bank statement when they receive the money

The next release is scheduled for the end of September

• Hook fixes

We’e reworked Hooks and Events to ensure assure events trigger the various hooks (noteably PAYOUT_NORMAL_CREATED which previously wasn’t systematically triggered)

• Custom sorting for User and Event lists

You can now also change the sort direction of the user and event lists

The next release is scheduled for the begining of December

This minor API version relates to having more detailed addresses for Users and Bank Accounts. It will be available from 20th July 2015 and will mandatory from 15th September 2015 if you wish to do PayOuts to CA or US type bank accounts.

Changes to API objects

An address is currently used in the follow objects:

• Natural User – Address
• Legal User – LegalRepresentativeAddress and HeadquartersAddress
• BankAccounts – OwnerAddress

In each case, the previous string format is no longer accepted, and a more detailed array of information is required. Further information is available below:

As with the previous address fields for the User, it is still optional to provide the address information when creating a User, however if you do provide at least one of the new address fields, you must provide a complete address (except AddressLine2).

Example request for POST /v2.01/:ClientId/users/natural/

Changes to API calls

POST /users/:UserId/bankaccounts/

The OwnerAddress field no longer accepts a string, but instead an array of fields, as detailed above. This sub-object is still a required property when creating a Bank Account

POST and PUT /users/natural/

The Address field no longer accepts a string, but instead an array of fields, as detailed above. This sub-object is still optional when creating a User.

POST and PUT /users/legal/

The LegalRepresentativeAddress and HeadquartersAddress fields no longer accepts a string, but instead an array of fields, as detailed above. These sub-objects are still optional when creating a User.

Updating historical data

In v2.01 it is not possible to obtain the address you added with v2 – you are therefore advised to migrate this information between the two versions (in the mean time, an address added in v2 will be shown as null in v2.01).

You can use the PUT method to update the additional address info for previously created Users. However, there is no PUT method to update Bank Accounts (due to compliance and traceability issues), which means you will have to create a new Bank Account with the additional address info and stop using any previously created Bank Accounts.

This release includes improvements on some error messages; New API call to get a KYC document; PayOut refunds in transaction lists, The local mean of payment iDeal.

Major updates included in this release:

• iDeal payment method [From v2.0]

Add the local payment method iDeal

• PayOut refunds in transaction lists [From v2.0]

Fix a potential problem showing PayOut refunds in transaction lists

• New API call to get a KYC document [From v2.0]

Add a new API call to get a KYC document with just the DocumentId (ie a UserId is not required) – this facilates the KYC Hook events where a UserId wasn’t present

Minor updates included in this release:

• Error parameter messages [From v2.0]

Improve several parameter error messages for incorrect CardTypes, Countries, etc

• Specific error message for wrong Address format [From v2.01]

Add a specific message when the Address is provided in the wrong format for Users and BankAccount objects

• Specific error message for Card Registrations [From v2.0]

Improve the error messages shown for Card Registrations

• Specific error message for a KYC [From v2.0]

Add a specific message for a KYC page that is too small

• Specific error message for Transfers [From v2.0]

Add a specific message for Transfers between two wallets with a currency mismatch

• Specific error message for registered card [From v2.0]

Add a specific message when trying to disactivate a registered card that is already disactivated

• BankWireRef [From v2.0]

Increase the length of the BankWireRef permitted for PayOuts to 12 characters

This small release includes some minor fixes and improvements.

Functionality improvements included in this release:

• Accept spaces in Postal Codes [v2.01]

Following client feedback, you can now use spaces in the PostalCode field for detailed addresses (for bank accounts and users) – more info

• Add new call to view disputes for a PayIn [From v2]

We’ve added a new call GET /payins/:PayInId/disputes/ to be able to view the disputes for a particular payin

• Masterpass, Sofort, Giropay and iDeal payins are now refundable [From v2]

You are now able to refund Masterpass, Sofort, Giropay and iDeal payins in the same way as for most other payins

• Preauthorisation error code now specified [From v2]

In some cases, you could obtain an error 500 when capturing preauthorisations – this has now been altered so that a specific error code is given instead

Stability improvements included in this release:

• Fix a bug with transfer settlements following a dispute [From v2]

There was a bug in some cases when doing a transfer settlement whereby the transaction would fail – this has now been corrected

• Fix a minor bug with BankAccountId in PayOuts [From v2]

There was a rare bug where in some cases an incorrect BankAccountId in a PayOut would result in an error 500 instead of a specific error 400 – this has now been corrected

This small release includes some minor fixes and improvements

• Fix PayIn BankWire OwnerAddresss [v2.01]

The OwnerAddress property is now a detailed address object, as for other address fields in v2.01 (more info)

• Allow address fields to be nullable [v2.01]

Address fields in v2.01 can now be nullable, meaning they don’t have to be updated during a PUT

• Make the version case insensitive [From v2.0]

Previously the version used in the URL was case sensitive, causing error 404s in some cases

• Specify some iDeal error codes [From v2.0]

Various iDeal transaction errors will now be correctly typed as for other transactions (more info)

• Fix a potential bug on User lists [From v2.0]

A minor improvement has been applied to the User list call to prevent an 500 in some rare cases

This release focuses primarily on the release of the new Disputes functionality and some other minor improvements and bug fixes.

Major updates included in this release:

• Handling of Disputes [From v2.0]

For each chargeback, you’ll find a Dispute case that you can view and manage from the API or your Dashboard – you’ll also be sent an email notification. There is no breaking change to the previous workflow as such, but there are a few important improvements you should be aware of – more information here. From API point of view, there are new events/hooks, dispute managements and dispute document management (all of which can be handled from the Dashboard as usual)

• New PayIn method – Bancontact/Mister Cash (BCMC) [From v2.0]

BCMC is now available as a card payin (direct/token or via the web interface) – more info

• Postal codes no longer required for certain Countries [v2.01]

We’ve adapted the constraints when adding detailed addresses in v2.01 so that PostalCode is no longer required for countries that do not support this data – more info

Minor updates included in this release:

• PayIn URLs [From v2.0]

The URLs used for PayIns (ReturnURL, SecureModeReturnURL etc) can now be much longer than previous

• Fix ResourceId bug for PayOut refunds [From v2.0]

Fix a bug where the ResourceId for a payout refund in the events list could be wrong

• Fix a PayIn refund problem [From v2.0]

Non-EUR PayIns with fees could in some cases not be refunded – this is now fixed

• Add some iDeal specific error codes [From v2.0]

For certain iDeal error casses – more info (under the "iDeal" heading)

• Add further stability to sandbox [From v2.0]

In certain rare cases, the sandbox could respond with error 500s at times – this has now been fixed

• Prevent refund of disputed PayIns [From v2.0]

If a PayIn has a dispute against it, the transaction can no longer be refunded

In order to reinforce payment transaction security and to respond to new PCI-DSS requirements, our PSP has decided to make changes to some internet protocols. In particular, the TLS 1.0 protocol will not be accepted anymore: payments with browsers using this protocol will therefore not be authorised.

Planning for update

• Sandbox: 18/11/2015
• Production: 24/02/2016

Browser – outdated version list :

• Google Chrome: versions lower than 22
• FireFox: versions lower than 27-22 (versions 23 to 25)
• Internet Explorer: versions lower than 11 (for versions 8 to 10, a manual update is required [please see below])
• Opera: versions lower than 14 to 16 (for versions 10 to 12.17 a manual update is required [please see below])
• Apple Safari: versions lower than 7

In order to update your browser, you need to follow the below procedure:

• Go to the Options part of your browser
• Choose “Advanced settings”
• Activate the options “TLS 1.1” and “TLS 1.2”:

We’d like to draw your attention to an improved process for treating PayOuts which may well require your attention. The aim of this improvement is to more efficiently process PayOuts that are pending due to KYC checks or insufficient funds. Indeed today, even if a PayOut is rarely rejected, the solving process is entirely manual and creates delays and confusion.

Starting from 15th April 2016, your blocked PayOuts will be automatically rejected, and will have the Status “FAILED” with a specific “ResultCode” in the following cases:

• If a User needs to be KYC authenticated, you will need to go through the normal KYC process for the User (obtain the necessary KYC documents and upload them via the API – or via the Dashboard) and await validation before requesting the PayOut again. The ResultCode "02998" will be used if the bank account owner needs to be KYC verified, or "002999" if it is a debited user from the wallet that needs to be KYC verified (both these codes are new)
• If it is due to insufficient funds, you will need to make arrangements to have sufficient funds in the wallet before requesting the PayOut again Please note that once you have resolved a failed PayOut, you will have to request an entirely new PayOut. Besides, if a relevant KYC document and PayOut are made at the same time, the PayOut will not be refused unless the document is then refused. The usual ResultCode "001001" will be used in such cases

Important notes

• You must make the appropriate changes before 15th April 2016 , but we can update your account before then if you wish
• This new process will be set-up by default for all new clients from 15th January 2016 onwards. This means that if you have already created your sandbox ClientId but not your production ClientId, you should take this new behaviour into account before going live.
• You are strongly advised to make use of the hook notifications we currently offer, particularly PAYOUT_NORMAL_FAILED so that you can be alerted in the cases where the PayOut failed. You may also want to check for any failed/pending PayOuts on your side when the KYC_SUCCEEDED Hook is triggered. Click here for more info.

Please review any potential impact with your developers to see if a modification is required for your application to function correctly – it is possible that you already have a system in place to manage failed PayOuts and therefore no further action is required on your behalf. However, if your application cannot currently deal with these cases, after 15th April 2016 it is possible some of your PayOuts are refused and therefore go unnoticed to you, meaning the funds will remain in the User’s Wallet rather than being sent to their bank account as you had requested.

Feel free to get in touch with us if you have any further questions – we recommend discussing this information with your developer(s) first though, as they best know your application’s processes and requirements.

This major release includes some general fixes and improvements as well as some great new functionality!

Functionality improvements included in this release:

• KYC blocked PayOuts are now refused automatically for new clients [From v2]

PayOuts that are blocked due to KYC limits are now automatically refused if there isn’t a KYC document pending verification – more info. This will come into affect for old clients from April 2016

• Add idempotency support [From v2]

We’ve added an optional new feature for all POST requests that helps prevent duplicates – more info

• New aliases for client wallets [From v2]

You’ll notice that your client wallets (Fees or Credit) now have a specific alias for their ID – for example, your Fees EUR wallet will now have the ID "FEES_EUR"

• Add new endpoint to view transfer settlements [From v2]

We’ve add the endpoint /settlements/:SettlementId/ to view the details of a transfer settlement – more info

• Przelewy24 PayIns can now been refunded [From v2]

It is now possible to refund Przelewy24 PayIns in the normal way – more info on payment methods

• PayOuts were the funds are no longer available are now refused automatically [From v2]

If there are no longer sufficient funds in the wallet to do a PayOut when processing it, we’ll now automatically refuse it

Stability improvements included in this release:

• Fix a bug with preauthorizations not working in some cases [From v2]

There was a bug in some unique cases when doing a payin preauthorization and it would fail – this has now been corrected

• Specify a PSP error where the connection was lost [From v2]

In some rare cases when the connection was lost with our PSP, we didn’t correctly handle the error – this has now been corrected

• Fix confusing error messages for PayOuts <0.10EUR [From v2]

PayOuts for less than 0.10EUR (or the equivalent) previously had an incorrect error saying that there were insufficent funds – this has now been corrected

This small release includes some minor fixes and improvements

Functionality improvements included in this release:

• Idempotency lookup specific error message [From v2]

When the service is unavailable, there’s now a specific message detailing as such for GET /responses/:IdempotencyKey/ – more info

• Add specific error for preauth currency mismatch [From v2]

We’ve now added a specific error message if the currency of your preautorized payin does not match the currency of the original preauthorization – more info

• Update verification when creating disputes [From v2]

The verification when creating disputes has now been updated to allow for payins with a failed refund to be disputed

• Fix a bug with user card list [From v2]

We’ve fixed a bug with the pagination of card lists

• Fix an ambiguous error message for incorrect UserId [From v2]

When doing a GET /users/:UserId/ with a UserId that contains an alphabetic character was previously returning an ambiguous error message which has now been clarified

• Add new endpoint to add funds to client credit wallet [From v2]

We’ve add a new endpoint POST /clients/payins/bankwire/direct/ to create a bankwire payin to a credit wallet (more info to follow)

This major release includes some new functionalities as well as some minor fixes and improvements.

New functionalities included in this release:

• Direct Debit payments [From v2]

You can now do PayIns via direct debit (although in production you’ll need to contact support to have this activated for your account) – more info

• New API endpoint to specify branding preferences [From v2.01]

We’ve added a new endpoint allowing you to upload your company logo and choose various theme colours – currently this is only used for the direct debit PayIns but they will be used elsewhere soon – more info

Minor improvements included in this release:

• Fix an occasional bug with iDeal payments [From v2]

There was a bug in some unique cases when doing an iDeal PayIn whereby it would be prematurely failed, even though it was later successful – this has now been corrected

• Improve idempotency support [From v2]

In some cases, the response given for an idempotency key lookup was wrong – we’ve reviewed this and added a patch to ensure it can’t happen (more info on idempotency support)

• Improve transactional emails [From v2]

We’ve started work to improve the design and deliverability of our transactional emails

• Improvements to refund checks [From v2]

We’ve added a couple of improvements to the way we check various things before doing a PayIn refund to ensure better reliability