March 2018

Scheduled 8 March 2018

Transaction records fix

We’ve fixed an issue with the Dashboard Transactions page wherein the most recent records of any transaction (in particular, in the Disbursements tab) were missing due to a code behaviour.

You will now be able to see these missing records.

1 March 2018

Updating the seller fee cap

Last week, we added a cap to the seller fees so that these will never exceed or equal the cost of the good or service rendered. We’ve revised this to allow seller fees that are equal to the cost.

February 2018

22 February 2018

Capping seller fees to the item amount

We’ve added a cap to the seller fees so that these will never exceed or equal the cost of the good or service rendered. (Otherwise, the seller doesn’t get paid out at all.)

Release scheduled: 15 February 2018

500 error on pre-live

We’ve fixed an issue which caused a 500 error when users attempt to make a payment in the pre-live environment. Users can now resume testing payments without incident.

Release date: 1 February 2018

  • In line with PCI requirements, we are removing support for TLS versions 1.0 and 1.1 for our analytics services (through Analytics or the Dashboard).
  • This removal may affect the experience of people using web browsers older than Chrome version 32, Firefox version 27 , IE 10, Opera version 12, and Safari version 7. We advise updating to the current browser version to avoid possible impacts.

January 2018

Release date: 24 January 2018

Improved fees handling

  • We’ve fixed an issue where a marketplace couldn’t release a payment when Assembly fees were zero for the transaction. This is now resolved.

December 2017

Release date: 7 December 2017

User underwriting threshold fix

  • We’ve corrected a behaviour in our underwriting feature which reset a user’s underwriting threshold to platform defaults when the user’s profile was updated. This is now fixed. Typically, when users update their profile information, they retain their current underwriting threshold.

Bank fixes

Account number display

  • We’ve fixed a bug which totally obscured a user’s bank account number (thereby making it very difficult to investigate a user’s bank information). We’ve applied the fix to display the last 3 digits, as designed.

US routing number issue

  • We’ve fixed an issue which arose regarding US routing numbers. An unforeseen change in our system affected how we passed and retrieved routing number information for US bank accounts. Users should now be able to input US routing numbers without issue.

November 2017

Release date: 23 November 2017


  • We are now improving the way that our core system processes transactions in production—you’ll see response times drastically decrease, and transactions per second drastically increase!

Release date: 2 November 2017


  • We noticed that our rules engine and underwriting thresholds often trip our customers when they’re testing in pre-live. Because our rules and thresholds aren’t as meaningful with fictitious people and transactions, we’re giving our customers the option to disable these in pre-live.

October 2017

Release Date: 9 October 2017


We’ve fixed an issue on the validation for the routing number field when you create a bank account. The routing number field once more accepts alphanumeric values for countries outside of the USA, Australia, and New Zealand.

Please note that the following validations apply for these countries:

  • USA — Must be a valid US routing number. US routing numbers can be looked up online, or can be obtained by your users from their bank.
  • Australia — Must be a six-digit BSB number. BSB numbers can be looked up online, or can be obtained by your users from their bank.
  • New Zealand — Must not include any value at all, as the routing number is already included with the bank account number

Users with Australian and New Zealand bank accounts will still be unable to add SWIFT codes for international disbursements for the meantime.

Release date: 5 October 2017


  • We have fixed the error messages a user received when they try to create invalid card account and invalid milestone.

Release date: 3 October 2017


  • We have moved the “Getting Started” information on the PreLive environment into its own section now titled ‘Integration Overview’. This will be the default landing page for all prelive users.
  • In the past, we’ve had customers who are unable to refund an item’s remaining amount in escrow after a partial payment or partial refund had been done. This is because our platform calculated the outstanding amount inaccurately and thus, does not validate the partial amounts being entered. We’ve fixed how the outstanding amounts are calculated so that these refunds can now be completed.
  • To make our refunds cleaner and more understandable, we’ve added two fields in the Fees section of the Item Details:
    • Refunded shows amounts refunded to a buyer. These would typically exclude non-refundable fees that the buyer had paid out.
    • Assembly fee shows the fees the platform had retained during the refund.

September 2017

Release date: 14 September 2017


  • We’ve updated the Getting Started section under Account. This section now showcases some of our documentation resources to guide you towards the right direction when integrating with our service.
  • We’ve also added a section called Your Details, which shows the principal account details of your platform.

August 2017

Release date: 31 August 2017


  • We’ve resolved a technical issue with one of our payment gateways, which caused some transactions to be denied.
  • We’ve fixed an issue where buyers were not being notified when a seller requests payment.

July 2017

Remember to clear your cache in order to properly see these updates!

Release date: 31 July 2017


We’ve rolled out the new and improved Management Platform, which is now simply called the Dashboard! Here are some of the changes you’ll see with it:

  • We’ve updated the look and feel to reflect our branding, with fresher, bolder colours and better contrast for your viewing pleasure.
  • Dashboard and Reports are now under Analytics, with Dashboard now called Overview to avoid confusion. This is also now your landing page.
  • Items and Transactions menus are now under Payments.
  • Your Users are still there, in a menu called Customers for clarity.
  • Your platform Account details, as well as Fees, can now be viewed under Settings.

We are also introducing Virtual Terminal, which gives you an easy way to capture card payments from your users onto your platform, as needed. When enabled, the Charges API powers the Virtual Terminal function, which is found on its own Virtual Terminal menu under Payments.

A few characteristics:

  • The menu provides user and card account validation so that you are assured that it charges the correct user.
  • Items charged using Virtual Terminal are prefixed “VT-” on their item ID.
  • Items charged using Virtual Terminal have your platform as the seller.
  • When viewing an item’s details, there is also a new field called Virtual Terminal to indicate whether the item was charged accordingly.
  • Error handling will follow; for the meantime, a typical reason for your charge to fail is if you input user or card information that are inconsistent with the information on your platform.

See our new guide on Virtual Terminal for more information.

We always want you to have a seamless experience; thus, the Dashboard as you know it is still accessible by its URL, Stay tuned for updates as we rebrand the URL as well.

June 2017

Release date: 5 June 2017


  • We’ve improved our Approve product with the following new features:
    • You can now include PDF invoices available through a link sent directly to your users.
    • The Approve UI can now be customised to include your platform’s logo and branding.
  • Contact our Integration Team if you’re interested in applying these new features.
  • In addition, we’ve made our messages simpler, as well as improved our mobile interface to validate user data more accurately, and to enable end users to choose whether their credit card information is saved or not after a successful transaction.

May 2017

Release date: 26 May 2017


  • We’ve fixed an issue wherein direct credit transactions that have invalid bank details end up getting included in the batch transaction process before the bank account details have been corrected.

Release date: 19 May 2017


  • We’ve fixed a prevailing issue with the Show Batch Transaction API call. Previously, this call would display the wrong transactions associated with an item. We have robustified our code to ensure that this error does not occur anymore.
  • We’ve fixed an issue on our Approve product which yielded a 500 error when a user tries to pay with a newly created bank account. Your users can now proceed with this action without issue.

Release date: 12 May 2017


  • We’ve updated the workflow for when we try to disburse funds to a seller with invalid account details. Now, we credit the funds back to the seller’s digital wallet so that the same payment workflow can still be used to disburse the funds after the seller corrects his or her bank account details.
  • Onboarding emails (such as email confirmation and password resets) now send instantaneously, ensuring that customers can use our platform as soon as their accounts are set up.


  • We’ve fixed a bug which prevented individual transactions from a bundle direct debit transaction from being marked ‘Successful’. Additionally, we fixed a related bug wherein items in a bundle direct debit transaction did not revert to ‘Pending’ state when the batch itself is marked ‘Invalid Account Details’ or ‘Failed Direct Debit’.
  • We’ve also resolved an issue wherein callbacks were not being triggered when an batch transaction state is updated.

Release date: 3 May 2017


  • Items on the Management Platform now display an item’s batch status under Item details for direct debit transactions. This field appears as soon as the item is included in a batch transaction.

April 2017

Release date: 27 April 2017


  • We have added an SMS receipt with our Approve product. Upon payment via SMS, the user now receives a message containing the item details and a link to the invoice.
  • We have improved the behaviour of test transactions for direct debits on pre-live so that the transaction statuses update to successful every 5 minutes. Your developers can now test the complete direct debit workflow, including refunds for these test transactions, more quickly.

March 2017

Release date: 28 March 2017


  • We have streamlined the way we process transactions which are funded by direct debit. This will allow us to manage these transactions from start to finish more efficiently.
  • Further to this, we have introduced some new batch statuses which will allow customers to see what the status of a direct debit transaction is up to:
    • Bank Processing: This means the transaction is currently being processed within the 3-day timeframe.
    • Pending Successful: A direct debit transaction has not bounced after 3 business days, but needs to be reviewed by our Payments Team before it is tagged successful.
    • Invalid Account Details: The bank account details supplied are incorrect. Please contact the user.
    • Failed direct debit: The transaction has been dishonoured due to insufficient funds or other restrictions. Please refer user to contact their financial institution.


  • We have fixed a bug wherein successful refunds made for digital wallet transactions did not show the correct item state.

Release Date: 24 March 2017


  • We have updated our PromisePay.js library with more robust validation for your users’ credit card information, which ensures that the values entered are acceptable.
  • In addition, PromisePay.js is now a standalone library and no longer requires the use of a jQuery library. This prevents conflicts that may occur with your existing libraries.

Release Date: 17 March 2017


  • Following recent changes to how Credit Card transactions are processed in the United States, our US customers will no longer be able to use our Soft Descriptors feature. Instead, credit card statements for these platforms will show either an individual seller’s name or the name of the platform:
    ASM*Samuel Seller
    ASM*Platform Name

    Contact Assembly support to ensure that your US-based platform is set up for these new descriptors accordingly.

Release Date: 10 March 2017


  • Following our rebranding, Soft Descriptors appearing on credit card statements will change from PRM* to ASM*.

Release Date: 10 March 2017


  • You can now add administrators with read-only access to your platform. Please see our guide on User Permissions for more information. Contact Assembly support if you want to apply read-only permissions to admins on your platform.


  • We have fixed an issue which showed an items total amount as $0.00 after the transaction is completed.
  • We have fixed an issue which displayed the “Payment Type” field of an item as blank when the Charges API is triggered.

Release Date: 7 March 2017



We fixed a bug which was causing User IDs to be generated as a hex value when the generate_user_ids feature configuration was turned off.

Customers who have the feature configuration enabled to generate User IDs may see a new universally unique identifier (UUID) format for their User IDs coming through.

If you have questions or concerns regarding the new UUID format, please contact Assembly Support.

February 2017

Release Date: 22 February 2017


  • As an added security feature, your platforms principal will now be notified via email when the bank account details of your platform changes. This protects you from unauthorized changes to the bank account into which fees are disbursed to your organization. Please note that Assembly will also be notified of such changes.
  • Soft Descriptors are now available for the Charges API.

Release Date: 17 February 2017


  • We are introducing pre-authentication in this release which allows you to have more control over credit card transactions on your platform. See our new guide on Pre-authentication of Credit Cards if you are interested in incorporating this new feature into your platform.
  • You can now set a minimum amount for items being transacted on your platform to better meet your business needs. Contact Assembly Support if you wish to configure this feature.
  • You can now choose how credit card numbers are displayed on your platform—you can display the first 6 and last 4 digits, or just the last 4 digits:
    1234 56XX XXXX 7891

    Contact Assembly support if you want to configure your platforms’ credit card number display.


  • We have fixed an issue where an item retains a refund_pending state instead of reverting to completed when a refund action fails due to an expired card.
  • We have fixed an issue which prevented platforms from refunding an item amount where marketplace fees are being refunded as well. Marketplace fees can now be refunded as needed, regardless of the amount held by the marketplace’s digital wallet.
  • We have also fixed an issue which prevented refunds when the platform fee being refunded is very small (usually, for fees less than 1 cent).

Release Date: 16 February 2017


We have added a new area in the Management Platform titled “Refund Status” so you can track the progress of a refund after it has been initiated. If an item has no refund in progress, nothing will be showing in this column. For a description of refund states please see our API Reference Guides.


IMPORTANT: Please clear your browsers cache to see these changes take effect.

Release Date: 14 February 2017

PromisePay has officially rebranded as Assembly!

To ensure that your user and platform experience will be seamless and with minimal impact, please note the following as we transition into our new brand of business.


Our environments remain the same at the moment. Thus, you can keep using the following as normal:


Our integrations remain the same at the moment and you may continue to use these as normal. Thus, the procedures for Integrating PromisePay.js and Using Assembly SDKs largely remain the same. Our repositories on GitHub will also remain the same, however, will be renamed under Assembly in the near future.

API Endpoints

Our API endpoints remain the same for the time being and you may continue to use these as normal. Note that some elements will persist representing PromisePay for the meantime, such as URLs, email addresses, and parameters like the promisepay_fee.

Future Releases and Updates

As more changes occur, we will keep our Documentation Portal up to date with the latest information so that you can be guided accordingly when you need to make changes to your platform’s configurations. To learn more about Assembly click here.

Release Date: 2 February 2017


  • We have made changes to how we onboard US platforms; if you are registering a business as Platform Principal, you can opt to provide either your own SSN or your business’ EIN as part of our KYC requirements.
  • We have updated the schedule of our morning batch processing to run two hours later, at 8:00 AM AEST (9:00 AM AEDT), which is 5:00 PM EST (US). This ensures that our Payments Team are able to clear more transactions for our US customers.

December 2016

Release Date: 16 December 2016


  • Recently we encountered a bug causing unexpected error messages in the case of a credit card payment failure. This has been fixed so the system shows the proper error message.
  • We have fixed a bug wherein callbacks didn’t get triggered when an item’s state changed.

Release Date: 9 December 2016


  • You can now process partial refunds for items that have already been completely paid for and released to the seller’s bank account. In line with this, we created a feature configuration which enables you to choose how your platform processes refunds for these completed items. With this feature configuration, you can set refunds of completed items to be processed through a direct debit from the seller’s bank account instead of being taken from their digital wallet.
    Please note: Our system will not refund fixed fees incurred by users in your platform for cases of partial refunds.


  • We have updated the schedule of our afternoon batch processing to run an hour earlier, at 3:00 PM AEST; this ensures that our Payments Team are able to clear more transactions daily.


  • We have resolved an issue that arose recently wherein users were unable to confirm their payments through our mobile authentication feature.
  • We have fixed a bug that prevented buyers from requesting a refund for items that have been partially paid for, but not yet released to the seller.
  • We have fixed a small bug which displayed negative values in the released amount field after an item associated with older seller accounts was refunded.
  • An issue has been resolved where refunds for partial payments initiated by sellers were not actually triggering the refund to happen.
  • We have fixed a bug which inadvertently released funds in escrow when sellers requested payment without prompting the buyer for their agreement.
  • We have updated the information displayed by our Item API calls to include an item’s refund state, so that you can see the current status of an item pending refund.

Release Date: 1 December 2016


  • We have made changes to our indexing which have resulted in a huge performance improvement to payment times.
  • Specifically, customers will notice our Charges and Release Payments APIs are now running significantly faster.

Release Date: 1 December 2016


We have made some changes to the way our API calls are executed

  • Particularly when you’re fetching information on your users, items, payment accounts and transactions.
  • These changes make the system run more smoothly and reduce the time it takes to generate the information you ask for.

November 2016

Release Date: 23 November 2016


  • We fixed a bug where bank account numbers longer than nine digits were being truncated in the system, thus preventing their related transactions from being processed.
  • We have fixed a bug found in pre-live that left certain direct debit transactions stuck in a payment pending state. This fix ensures that your platform seamlessly processes direct debit transactions in the production environment.
  • You can now set up platforms which default to the New Zealand dollar as its currency.
  • We fixed a bug that displayed “PromisePay” on your customers’ statements for credit card transactions used to fund digital wallets. The descriptor on your customers’ credit card statements will now show your platform name appended to “PRM”; for example: “PRM*PLATFORM”.
  • We tweaked our feature configurations and payment restrictions APIs to return the error code 422 (unprocessable entity) when you specify a nonexistent configuration or restriction.
  • We fixed an issue where refunds for payments made through wire transfer were being marked successful without being processed.
  • We have fixed an issue that caused any assigned Custom Descriptors applied to a user to be reverted back to default settings when that user’s details are updated.
  • We fixed a bug with our batch transactions API calls wherein the call returned nothing when you specified an account ID.

October 2016

Release Date: 13 October 2016


We’ve made some improvements to our APIs related to making and releasing payments. Our Make Payment and Release Payment calls now use eager loading, which will improve the processing time of transactions for our customers resulting in a faster payment experience.

Release Date: 13 October 2016


  • Previously, the status icon in the Items menu did not render properly and instead showed a broken image icon. We have fixed this issue so that the icons now load properly and will show the item’s status on mouseover.
  • We have fixed an issue in the Transactions menu that prevented items paid through direct debit from being displayed under the Direct Debit tab. Items are now displayed correctly, under the tab corresponding to the source of payment.
  • Further tweaks have been made to our Transactions menu so that you will no longer see pagination options when the records listed all fit in in one page. Additionally, we have fixed the text alignment of the records listed so that they all look nice and orderly even when an item name is unusually long.
  • Our contact email address in the Getting Started section of the Account page has been updated. You can now email us at for help in setting up your platform environments and we can get back to you much quicker!

Release Date: 11 October 2016

Capturing Bank Account Details

In addition to securely capturing credit card details, your platform can now capture a user’s bank account details through the PromisePay.js package, resulting in the creation of a bank account token. Similar to credit card tokens, bank account tokens can be used to securely send bank account details within your platform.


  • In light of the switch to Australian daylight saving time, we have adjusted our production batch processing to ensure they continue to run on their usual schedule:
    • Morning run: 2000 UTC / 0700 AEDT / 0600 AEST
    • Afternoon run: 0500 UTC / 1600 AEDT / 1500 AEST
  • With our soft descriptors, we have tweaked the code to show a user’s company name, whenever available, on the statement.

Release Date: 04 October 2016

Soft Descriptors

Soft Descriptors are now available. This allows platforms control over the information that appears on their customer’s statements. There are two primary functions related to the feature; Dynamic Descriptors, which display a set of default information on a customer’s statement, based on the payment method, and Custom Descriptors, which allow further customisation of statement information in order to meet a platform’s requirements. The following examples illustrate what a buyer would see on their credit card statement:

  • Dynamic Descriptor – “PRM*SAMUELSELLER”
  • Custom Descriptor – “PRM*TASK123456”

The documentation for Soft Descriptors is now live on our Documentation Portal.

September 2016

Release Date: 20 September 2016

Event Logging

We have streamlined the way our database captures and stores historical data for changes and updates to both items and users. For example: whenever the state of an Item changes or fails to change when it should, we record the action plus date and time stamp into an event log specifically for that item. This will allow us to improve our reporting capabilities in the future.

Release Date: 19 September 2016

Australian Financial Services Licence (AFSL)

PromisePay has completed necessary upgrades in order to fulfill our obligations as part of our AFSL agreement.


We have fixed a bug that was stopping penny credits from being cleared when a seller’s bank account was not yet verified.

Release Date: 6 September 2016

Penny Credits

We have developed the ability to verify a user’s bank account by use of penny credit verification. When a user adds a new bank account to their profile you have the option to trigger several small credits to be sent to those account details. The user will then be prompted to confirm what the two individual amounts were to verify they own that bank account and that the account information provided is correct.

Documentation on how to set up Penny Credits is live on our Documentation Portal.

Refunding Released Items

In the event we need to refund a purchaser after the funds have been released to the seller, we now have the ability to refund Items that have already been released.

This can occur in the following ways:

  • We will attempt to pull funds from the Sellers digital wallet
  • We will attempt to pull funds from the Sellers bank account or credit card account

Reporting dashboard

We have implemented our reporting tool into the API and are now able to complete testing of embedding the reporting dashboard into the Management Platform.


We have fixed a bug that was causing customers to be charged a fee twice for a partial release.