I have set reqMarketDataType(MarketDataType.DELAYED). But then I am getting
"Requested market data is not subscribed"
error while fetching delayed data.
// API Version 9.72 and later Launch EReader Thread
m_reader = new EReader(client, m_signal);
m_reader.start();
new Thread() {
#Override
public void run() {
processMessages();
}
}.start();
Contract contract = new Contract();
contract.symbol("GOOG");
contract.exchange("SMART");
contract.secType("STK");
contract.currency("USD");
// Create a TagValue list
Vector<TagValue> mktDataOptions = new Vector<>();
// Make a call to start off data retrieval
client.reqMarketDataType(MarketDataType.DELAYED);
client.reqMktData(1001, contract, null, false, mktDataOptions);
}
Based on your market data type and error displayed, it is USA equity, you need to subscribe the market data. Please refer to the follow link:
The procedure to subscribe the market Data in IB
To use the market data page
Click Manage Account > Trade Configuration >Market Data.
Your current market data subscriber status (Professional or Non-Professional) is displayed in the page title. Market data subscriptions are organized by region (North America, Europe, Asia-Pacific).
The Market Data page appears.
To sign up for additional market data subscriptions, click the tab for the region you want, click the check box for each subscription you wish to add, then click Back.
If you have additional linked, duplicate or consolidated accounts, the Billable Account section appears on the page. Use this section to change the account that is billed for market data.
Select the account you want to be billed for market data, then click Change Billing Account. Beginning with the next billing cycle, your market data subscriptions will be billed to the account you selected.
To unsubscribe from market data, click the check box for the subscription to clear the check mark, then click Back.Read and complete any Subscriber Agreement that appears, then click Back.
The Market Data page opens again, with your new selections updated and any pending subscriptions identified as such. Market Data subscription updates take effect immediately under normal circumstances.
https://www.interactivebrokers.com.hk/en/software/am/am/manageaccount/marketdatasubscriptions.htm
Subscription considerations for U.S. market data (Non-Professionals)
Generally speaking, clients trading a broad variety of product classes should consider the basic bundled subscription referred to as the US Securities Snapshot and Futures Value Bundle which costs USD 10 per month and provides quotes for a variety of U.S. stocks, stock indices, bonds, futures and futures options. The monthly fee for this subscription is waived for any month in which the account generates at least USD 30 in commissions.
https://ibkr.info/node/2840
Related
I'm fetching my next upcoming invoice for a customer so that I can charge them immediately.
So I fetch the next/upcoming invoice object and I see the data being returned (see pic), but then in order to pay/charge the upcoming invoice I need to pass the invoice id on to the 'StripeInvoiceService' method 'Pay'. But there is no id for the upcoming invoice, the value is null! Am I misunderstanding something here? As far as I'm aware, when I create invoice items for a customer under a subscription an invoice is automatically generated for the next billing cycle containing all of the invoice items...
Here is my code to fetch the upcoming invoice and then pay it
// get upcoming invoice
StripeInvoice upcomingInvoice = new StripeInvoiceService().Upcoming(profile.StripeCustomerId);
// charge card
StripeInvoice invoice = new StripeInvoiceService().Pay(upcomingInvoice.Id);
Here is the data that is returned, it shows the invoice but no id.
This is expected behavior on Stripe's end. The Retrieve Upcoming Invoice API allows you to visualize what the next invoice for a customer's subscription will look like. You can use this API to tell your user how much they will pay next time or simulate an upgrade/downgrade of the subscription.
This invoice does not exist yet, it's just a preview of what will happen when your subscription renews. Since it does not exist, it does not have an id and can't be retrieved directly. You also can not pay this invoice in advance. It can only be paid on the day the subscription renews.
I am currently building out my iOS 10 app with user profiles, which should hold certain achievements and experience points (similar system to StackOverflow). I have already built my Facebook Login, FIRAuth etc. At the moment I am thinking about the data structure of Firebase's DB. I have read through the Firebase Guide for flat data structures and some general Firebase data guides like the one from Ray Wenderlich.
This is what users can already do:
login with Facebook (...) and get picture, name etc. (already handled via FIRAuth)
visit a profile page, which shows their name and profile picture (already handled in a ProfileViewController)
This is my to-do list:
basic achievements via badges/titles similarly to StackExchange/StackOverflow e.g. user has done action XY 20 times => badge for 20 times for action XY; I was thinking of either:
a) having an array/list in each of the users' profile, which holds all of the gathered badges (as strings) OR
b) having a single boolean var for each achievement within the user profiles
a second achievements tracker, which tracks the general usage of the app - something like a levelling system in RPG games with experience points so just an Int value for every profile in terms of the DB
My question:
How would you combine the FIRAuth profiles with the database to hold the aforementioned badges (could be up-to 50-60 achievements) and the separate levels/xp points of the users?
Keep in mind that I am new to the modelling of JSON DBs. I don't want a solution in terms of code etc. for the functions in question - just a helping hand for the data structure of the user profiles.
I would also be looking into the extension of the user profiles in the future (messaging etc.) and I should be able to send notifications to all users who have certain levels/achievements in the future (and this makes me lean towards b)) - so too much nesting is out of the question already.
Using the structure below, you can retrieve a particular user's achievements by observing the children of the user's achievements path. However this only get's you the keys of the achievements.
Given you have a user with the uid 1j6Ft1BT30TFG403obvGfjOHE4th, for each child in user-achievements/1j6Ft1BT30TFG403obvGfjOHE4th, you can use the child keys to observe the value of each achievement at achievements/-KQpsPExLsKdnVHMliiP.
{
"users": {
"1j6Ft1BT30TFG403obvGfjOHE4th": {
"username": "john"
}
},
"user-achievements": {
"1j6Ft1BT30TFG403obvGfjOHE4th": {
"-KQpsPExLsKdnVHMliiP": true
}
},
"achievements": {
"-KQpsPExLsKdnVHMliiP": {
//
}
}
}
Use case which we want to built is a user will be presented with a list of financial institutions and when he selects anyone of it he needs to provide credentials to authenticate for selected institutions. Then brokerage account will be shown, clicking on it results into fetching of all portfolio positions.
So far what we have achieved:
Fetching list of all institutions, this we can achieve using
API method: getInstitutions
Selects an institution and authentication is performed (I am not sure this is the correct way of doing, if there is another way to do it then please let me know)
API method: discoverAndAddAccounts
Get all accounts associated with it and using Brokerage account id fetch all positions:
API method: getInvestmentPositions
Using above will return all positions but we can not differentiate between 'buy' and 'sell' action of a position.
Note: We are using this gem for the same: https://github.com/cloocher/aggcat
Thanks in advance.
First you have to know the definition of an option:
DEFINITION of 'Option'
A financial derivative that represents a contract sold by one party (option writer) to another party (option holder). The contract offers the buyer the right, but not the obligation, to buy (call) or sell (put) a security or other financial asset at an agreed-upon price (the strike price) during a certain period of time or on a specific date (exercise date).
Then by looking at the Intuit documenation we can see that:
positionType string
This is used to explain how long a position is held and differentiate between writers and holders of an option or other security.
E.g. SHORT = Writer for options,
Short - Write for all other securities,
LONG = Holder for options,
Long = Holder for all other securities. For Bonds, it is always "LONG".
Event 6274606517 has multiple types of tickets, some of which have already ended. Two of the future tickets are sold out, two aren't. How can I get that information via the API?
You can get this in event_get by inspecting the tickets node.
Each ticket will include quantity_available and quantity_sold, in addition to other fields which I've left out:
"ticket": {
"currency": "USD",
"quantity_available": 6,
"quantity_sold": 1,
}
One thing to be aware of is that you must pass in your user_key to identify yourself as the owner of this event, since ticket sales are considered private.
If sold >= available, the ticket will be sold out.
I have a checkout process for a shopping cart that is currently storing credit card data in the session for retrieval once the user finalizes the purchase. The purchase process is set up such that the user inputs the credit card, views a confirmation page, and then finalizes the order. The confirmation and finalization actions are the only two actions that need access to the credit card data and to be safe all other actions should discard it.
Short of doing reflection in a base controller to check the current action the user is calling, I cannot think of an elegant way to discard the data on the disallowed requests. Additionally, if the user fails to make another request after entering the data it will linger in the session until they come back to the website- whenever that happens. One suggestion I was offered was encrypting the data into a hidden field and relying on the SSL ticket to prevent caching the markup. This seems like a fairly safe approach, but I don't much like the idea of placing the credit card data in a user-accessible location encrypted or not. Storing in the database is out because the client does not want credit card data saved.
What is the ideal approach to temporarily persisting sensitive data like credit card information across more than one page request?
Perhaps someone can tell me if this is a sufficient approach. I have set my Shopping Cart which is stored in the session to have a unique Guid generated every time the object is newed and that Guid is used as a key to encrypt and decrypt the credit card data which i am serializing with the Rijndael algorithm. The encrypted card data is then passed to the user in a hidden field and deserialized after finalize is clicked. The end result is a string much like this:
VREZ%2bWRPsfxhNuOMVUBnWpE%2f0AaX4hPgppO4hHpCvvwt%2fMQu0hxqA%2fCJO%2faOEi%2bX3n9%2fP923mVestb7r8%2bjkSVZDVccd2AJzCr6ak7bbZg8%3d
public static string EncryptQueryString(object queryString, Guid encryptionKey)
{
try
{
byte[] key = Encoding.UTF8.GetBytes(ShortGuid.Encode(encryptionKey).Truncate(16));//must be 16 chars
var rijndael = new RijndaelManaged
{
BlockSize = 128,
IV = key,
KeySize = 128,
Key = key
};
ICryptoTransform transform = rijndael.CreateEncryptor();
using (var ms = new MemoryStream())
{
using (var cs = new CryptoStream(ms, transform, CryptoStreamMode.Write))
{
byte[] buffer = Encoding.UTF8.GetBytes(queryString.ToString());
cs.Write(buffer, 0, buffer.Length);
cs.FlushFinalBlock();
cs.Close();
}
ms.Close();
return HttpUtility.UrlEncode(Convert.ToBase64String(ms.ToArray()));
}
}
catch
{
return null;
}
}
The best way to handle this scenario is to use a payment service that supports two things:
Authorization -> Completion semantics.
Tokenization
Authorization allows you to reserve the designated charge amount at the time the payment information is received, and then Completion allows you to commit the charge to the payment batch once the payment/order is confirmed. If the order is canceled, you don't have to issue a Completion and you can also attempt to delete the authorization as well.
Regarding tokenization, most gateways that support the aforementioned method of handling payments will return a token, typically a numeric id, for the pending transaction. The token may then be handled however you wish, as it has no value to anyone without access to your authentication credentials at the gateway. This transfers the burden of safety to the gateway as well.
Storing the actual credit card information in any way other than relaying a charge to a gateway/processor is a bad idea. Beyond the problems of securing the data, this will also put your application into card information storage scope for PCI/PABP, which entails a lot of rules and regulations that you won't want to deal with in your application. I believe there is also a regulatory fee that will be imposed in the coming year for compliant applications, reputedly $10k USD. All of this is likely not worth the trouble to you or your client.
Last, during intermediate processing (in-page/event/route handlers), you can use a SecureString to hold the contents of the data until you no longer need them.
SecureString class (System.Security) # MSDN
What about using TempData? You'd need to put the value back into TempData between the confirmation and finalization actions, but at least it will be discarded with each request. Note that TempData uses the Session for storage so it's no more secure while it's being stored, but it does have the automatic removal feature. I, too, would resist storing the number on the page. I suspect that this violates the PCI rules.
Another alternative would be to store the card info in a database. If you keep it at all in your application you're probably already subject to the PCI rules anyway. Storing it in the DB makes it easier as then you only need to put the billing card id in subsequent requests. This could easily be in a hidden field.
What country is this based in and what credit card companies are involved? The entire approach of actually sending full credit card numbers back to the client (in whatever form) makes this sound like you have not dealt with professional credit card handling (please don't take that as an insult).
Is your client willing to run afoul of Visa/MasterCard/AMC/Discover's collective rules for online credit card processing (PCI DSS)? Your client could end being barred by the major credit card companies from doing transactions with them. In general it is a very bad idea to try rolling your own online credit card handling solution - it's worse then rolling your own cryptographic algorithm, as there can be serious fines applied to your client (fine print in their merchant agreement). A true PCI DSS solution requires tens of thousands of dollars in certifications and audits to ensure it handles credit card data in a truly secure fashion - this is why almost everyone uses an existing online processor.