I have developed an online ticketing application that uses a simple form integration - it's been running successfully for some years.
I have been asked to extend this so that it can be used for phone payments.
The reason for this is that the ticketing application has a great many options before the final price is arrived at so the people taking the call could use the same software (with minor modifications).
I can't see any options in the integrations for doing anything like this. It's all for customer payments.
Can anybody tell me if this is possible (and if so, how)?
Here's my understanding. It comes down to AccountType when you make your request to Sage Pay.
That accepts three different values:
E - use ecommerce account
M - use MOTO (mail order/telephone order) account
C - use continuous authority account.
Depending on your merchant bank and what you requested when you set up your merchant accounts, you'll have a merchant account for each. Sage Pay will send your request to the correct merchant account. This is key because if you use M, you'll not be expected to use 3D secure for the card - and the expectation is that it will be you processing the card, not the customer.
Related
I am trying to get listings and/or the latest bids for the same ERC721 token from different marketplaces (such as Opensea or Looksrare). I know that those platforms have their own APIs but none are commercially available.
Any of the following solutions will be enough to fix the problem
retrieving the listing details since I know the collection address and the contract addresses of those marketplaces (either using Etherscan or any other commercially available API)
retrieving the latest/highest bid for that token associated with marketplaces (either using Etherscan or any other commercially available API)
This is an excellent question. The market is completely fragmented and for one to retrieve all the available pricing/listings/orders it needs a lot of legwork and connection to various APIs.
There are a few teams working on a common pricing API that can aggregate the pricing of an asset across exchanges and on multiple chains but none of them is public yet. One of that I know and I'm a beta user of is:
https://openstory.io
I also believe that Zora.co has a similar endpoint but only for the marketplaces that are built using their own API.
you should give module a shot! They have all data from most NFT marketplaces, I hope that's what you're looking for
we are working on a custom software integration with DocuSign.
DocuSign has many types of accounts and subscriptions providing certain limits of features and credits for these features. E.g. you can create 5 documents - so you have 5 credits to create documents.
We have custom software and one corporate DocuSign account within it, enterprise level.
And there are numerous (account1, account2, account3, etc.) accounts of DocuSign users. These users work with our custom software and as a result our corporate account.
We have a question:
our custom software connects to account1, account2, account3, etc. using our Key. And our custom software creates envelopes(documents) in account1, e.g.
From what account credits are written off?
From our corporate DocuSing account or from DocuSign user account?
Thank you.
The user account should have the appropriate subscription to send envelopes.
I'm making a desktop app for a company, and they would like to get it featured in the windows app store for Windows 10 users.
The app will likely only work on desktop computers, it's not designed for mobile. What it does is perform lookups on lists of cell phone numbers, and outputs a spreadsheet with carrier info, and it requires a credit for each cell phone number looked up. The credits are bought in bulk through the company's sales team, there is no automated method to purchase them.
Because there is no automated system, it would be difficult to set up in-app purchases, also if Microsoft takes a cut of in-app payments then it wouldn't be feasible due to the tiny profit margin of the credits. But according to this (section 10.8.1), if the app consumes anything that has to be purchased then it needs to use the in-app purchasing api.
Does anyone know if there's some way around this? Or if it only applies to regular apps and not desktop only ones, which I understand are a different type of listing?
I realise I can get a developer account and go through this with them but I don't really want to spend this company's money on the dev account if Microsoft are just going to say no.
Thanks :)
That section of the policy refers to payments taken within the application.
It doesn't sound like what your application will do though. Your application is allowing the allocation (spending) of credits bought separately.
It's a small distinction but an important one. You may have seen other applications work around such limitations by requiring the user to go to a website to buy something and then return to the app to use it.
When submitting the app there is a declaration for "This app allows users to make purchases, but does not use the Windows Store commerce system." You can read more about this declaration at https://msdn.microsoft.com/en-us/library/windows/apps/mt148523.aspx but this shouldn't apply to your scenario.
There are potential legal implications here and if the company has any concerns about entering a legal agreement with Microsoft regarding financial matters then they should seek appropriate legal council. Having a developer ask other developers about legal matters is likely only suggest asking a lawyer.
This is slightly unbeknownst to me. In WP8 store, if purchasing consumables, the client has to report fulfillment. Is this when the customer gets billed or do they get billed directly on purchase? i.e. Can the consumables be used like durables if fulfillment is not reported.
The customer gets billed when they purchase. You could choose to leave the IAP unfulfilled if you wanted to, but you'd need to report fulfillment before the customer could purchase that IAP a second time.
If you want to use the IAP as a durable though you should just use a durable. One thing to keep in mind is that if your app is uninstalled, then reinstalled (on same device or different device w/ same Microsoft account) you'll still be able to check for a list of purchased Durable IAPs using the ProductLicenses API. This list will not return info about the Consumable IAPs though, you're expected to fulfill those and track the consumable content through your own means.
I'm developing a web application for people who manage nonprofit organizations. This will require me to verify that certain users belong to a nonprofit. Here are a few verification methods I've considered:
Verifying the user's location through JavaScript's Geolocation API.
Maintaining a list of nonprofit domains and requiring that the user's email matches one of the domains.
Sending a physical letter to a business address.
Soliciting a phone number and calling the users to confirm their employment status.
None of these methods seem to be efficient or scalable. The first method may provide an extra little layer of security, but users can easily spoof geolocation. Is there a better way to accomplish this type of verification?